Processing 4.4.4 on Ubuntu 22.04 can’t access tty ports

Processing Beginners
1

Hello all,

I was using processing 4.3 on my Ubutun 22.4. This is a standalone installing fron a tarball.

I tried to install with SnapD, the latest release 4.4 and as for now I’m not able to use the tool for the same code.

I got a bunch of errors that may explain the behavior but I don’t know what is it

Gtk-Message: 11:56:09.913: Failed to load module "canberra-gtk-module"
[SKIKO] warn: Failed to create Skia OpenGL context!
java.lang.RuntimeException: Can't wrap nullptr
[SKIKO] warn: Exception in draw scope
org.jetbrains.skiko.RenderException: Cannot init graphic context
java.lang.reflect.InaccessibleObjectException: Unable to make field private static java.lang.String sun.awt.X11.XToolkit.awtAppClassName accessible: module java.desktop does not "opens sun.awt.X11" to unnamed module @7cc50c74
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Unknown Source)
	at java.base/java.lang.reflect.Field.setAccessible(Unknown Source)
	at processing.app.platform.LinuxPlatform.initBase(LinuxPlatform.java:56)
	at processing.app.Platform.initBase(Platform.java:112)
	at processing.app.Base.<init>(Base.java:531)
	at processing.app.Base.createAndShowGUI(Base.java:300)
	at processing.app.Base.lambda$main$0(Base.java:130)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
Exception in thread "Timer-0" java.lang.SecurityException: Could not lock User prefs. Lock file access denied.
	at java.prefs/java.util.prefs.FileSystemPreferences.checkLockFile0ErrorCode(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.lockFile(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.sync(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.flush(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.syncWorld(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences$3.run(Unknown Source)
	at java.base/java.util.TimerThread.mainLoop(Unknown Source)
	at java.base/java.util.TimerThread.run(Unknown Source)
/dev/ttyACM1
Exception in thread "Sync Timer Thread" java.lang.SecurityException: Could not lock User prefs. Lock file access denied.
	at java.prefs/java.util.prefs.FileSystemPreferences.checkLockFile0ErrorCode(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.lockFile(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.sync(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.flush(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences.syncWorld(Unknown Source)
	at java.prefs/java.util.prefs.FileSystemPreferences$4$1.run(Unknown Source)

Right now I can’t access to tty ports.
Is it a problem of installation or right/write access that I dont’ have ?

Thanks in advance

2

Hi @PyM72,

I’m wondering which version you’re running. In our 4.4.6 release (See Notes), we enabled classic confinement, which should help with some of these issues around access in the snap packages.

Let us know the version. If you’re on 4.4.6 and this is still a problem we can investigate further!

-Moon

3 Likes
3

You can download a zip version from Releases · processing/processing4 · GitHub and try that.

I did try the snap route (on Fedora) and had to revert to the zip because of serial port problems.

4

Hi @sterretje, these issues should be fixed in 4.4.6 with the switch to classic confinement. Would you be willing to try the snap again and let us know if the problems are resolved?

If the issue is still there, that will be helpful to know as well, so we can look into other possible causes.

(Raphaël)

5

Hi all,

@moon : I was using 4.4.4 for sure.
I uninstalled through out snap this release and downloaded the bundle mentionned by @sterretje

This release works fine at my end (even serial port). Which is nice indeed ! :slight_smile:

BTW I had another issue that I couldn’t explain though.

 ./Processing 
Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.

To workaround I found this command

cd lib
find runtime/lib/ -maxdepth 1 -mindepth 1 -exec ln -s {} \;

As for now I am able to use Processing. Thanks all !

1 Like
6

Hi @PyM72, thanks for confirming. The issue you’re describing should be fixed in the 4.4.6 release on Snap. If you could give it a try, that would help us check whether this bug is actually gone.

Of course, you can always stick with the portable version if that works better for you. But we really rely on the community to try out new releases so we can make Processing better for everyone. Your feedback is a big part of that!

(Raphaël)

7

For now the answer is “no”, sorry; too many projects (not related to Processing) with higher priorities. When I continue with my Processing application I will give it a try in Fedora (or which ever distro I will be using at that time); I live mostly in a Windows world.

8

Ok, let us know when you do!

For anyone else running into this, please give 4.4.6 a try :folded_hands: We’ve tested it on different distributions and machines, and it seems to work well, but feedback from people using it in their own setups is what really confirms the fix.

We know Snap has a bit of a reputation, and we’re working on Flatpak and .deb builds (see PR #1204), but this release should address most Snap issues, and community feedback is the only way to be sure it worked.

9

That work around is clever. Thanks for sharing! Now I’m curious about what we can do so you don’t have to do that. I’ve only been running processing on dev mode on on my linux machine, but I need to spend some time installing our releases :sweat_smile: