I've opened the app, went to appleiigs, opened the current machine configs and then pressed on the browse button on the first floppydrive. It opened a child window, before crashingXSetErrorHandler() called with a GDK error trap pushed. Don't do that.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f1ea00edfa0, pid=15990, tid=16062
#
# JRE version: OpenJDK Runtime Environment (11.0.6+10) (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1)
# Java VM: OpenJDK 64-Bit Server VM (11.0.6+10-post-Ubuntu-1ubuntu118.04.1, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C [libpthread.so.0+0x9fa0] pthread_mutex_lock+0x0
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /Games/Linux/Negatron-0.100/core.15990)
#
# An error report file with more information is saved as:
# /Games/Linux/Negatron-0.100/hs_err_pid15990.log
#
# If you would like to submit a bug report, please visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-lts
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)
XSetErrorHandler() called with a GDK error trap pushed error
XSetErrorHandler() called with a GDK error trap pushed error
I get the following error on Kubuntu 18.04:
Re: XSetErrorHandler() called with a GDK error trap pushed error
I'm on Fedora 31 and it was working fine as I never installed openjdk 11 before on my machine. I had Java 8, 13 and 14 installed.
But as soon as I installed Java 11, I got the same bug as you. And now even after removing Java 11, the bug remains with Java 13 and 14... probably due to some config left over by Java 11.
Now, it looks like the graphical library I use (OpenJFX 14) relies on GDK3 to handle stuff. And it looks like OpenJFX doesn't work well when GDK3 backend is Wayland instead of X11. Yet again, this bug is supposed to happen only with Java 11 and OpenJFX 11 and it should be fixed since OpenJFX 12+... still investigating this issue...
But as soon as I installed Java 11, I got the same bug as you. And now even after removing Java 11, the bug remains with Java 13 and 14... probably due to some config left over by Java 11.
Now, it looks like the graphical library I use (OpenJFX 14) relies on GDK3 to handle stuff. And it looks like OpenJFX doesn't work well when GDK3 backend is Wayland instead of X11. Yet again, this bug is supposed to happen only with Java 11 and OpenJFX 11 and it should be fixed since OpenJFX 12+... still investigating this issue...
Re: XSetErrorHandler() called with a GDK error trap pushed error
I finally understand what's happening. And it's indeed related to GTK3/GDK3.
Negatron uses OpenJFX as its main graphical library. And OpenJFX 11+ has migrated from GTK2 to GTK3 but, with GTK3, a lot of Linux distros have changed the graphical backend from X11 to Wayland. So, OpenJFX 11 couldn't work with those Linux distros using Wayland because OpenJFX 11 doesn't have a compatibility layer with Wayland, only with X11. To avoid having to develop a full compatibility layer with Wayland, OpenJFX 12+ simply added a hack to force GTK3 to work with X11.
The thing is Negatron uses VLC to play video files. And for this to happen, the library to embed VLC within Negatron (VLCj) uses AWT, another Java graphical library. AWT can work with X11 and Wayland without issues. So, I think that AWT overrides the hack used by OpenJFX and forces the use of the newest Wayland graphical backend, screwing up OpenJFX along the way...
So, I have 3 solutions at hand, sorted by increasing complexity and also from the worst to the best solution:
1/ completely rewrite the file chooser dialog box in pure Java, thus killing OS integration for those common dialogues in Linux, and hope that this GTK3 issue doesn't screw anything else up.
2/ rewrite a part of VLCj so that it doesn't use AWT anymore.
3/ write the Wayland compatibility layer that nobody at OpenJFX wants to write...
Negatron uses OpenJFX as its main graphical library. And OpenJFX 11+ has migrated from GTK2 to GTK3 but, with GTK3, a lot of Linux distros have changed the graphical backend from X11 to Wayland. So, OpenJFX 11 couldn't work with those Linux distros using Wayland because OpenJFX 11 doesn't have a compatibility layer with Wayland, only with X11. To avoid having to develop a full compatibility layer with Wayland, OpenJFX 12+ simply added a hack to force GTK3 to work with X11.
The thing is Negatron uses VLC to play video files. And for this to happen, the library to embed VLC within Negatron (VLCj) uses AWT, another Java graphical library. AWT can work with X11 and Wayland without issues. So, I think that AWT overrides the hack used by OpenJFX and forces the use of the newest Wayland graphical backend, screwing up OpenJFX along the way...
So, I have 3 solutions at hand, sorted by increasing complexity and also from the worst to the best solution:
1/ completely rewrite the file chooser dialog box in pure Java, thus killing OS integration for those common dialogues in Linux, and hope that this GTK3 issue doesn't screw anything else up.
2/ rewrite a part of VLCj so that it doesn't use AWT anymore.
3/ write the Wayland compatibility layer that nobody at OpenJFX wants to write...
Re: XSetErrorHandler() called with a GDK error trap pushed error
I think I'll go for fix 2/. It shouldn't be as complex as I expected.
On Windows and macOS, vlcj doesn't spawn any AWT threads and it shouldn't do so because Negatron embeds everything into OpenJFX. This is only done on Linux for some weird reasons. I'll go hunt and eradicate this.
On Windows and macOS, vlcj doesn't spawn any AWT threads and it shouldn't do so because Negatron embeds everything into OpenJFX. This is only done on Linux for some weird reasons. I'll go hunt and eradicate this.
Re: XSetErrorHandler() called with a GDK error trap pushed error
And I found the culprit!
It's fixed locally so the next version of Negatron will fix this issue. Cheers!
It's fixed locally so the next version of Negatron will fix this issue. Cheers!