What's this one mean, exactly?

A recent version of the Mesa OpenGL software changed the renderer string reported to GL applications. This broke JOGL which used this as an indicator to enable certain quirks that appear to be needed with Mesa. From looking at bug reports, this predominantly caused problems for users with dedicated AMD graphics cards.

THANK YOU. This Mesa issue was the only thing keeping me from using Processing on my Linux installation.

@serebit Could you test this jogl-all.jar file to see if it still works with your setup? https://sukzessiv.net/~gohai/p5/jogl-all.jar Please also report the output of glxinfo. Thanks!

Unfortunately, @gohai, the update still didn't fix Processing for me when I try to use the OpenGL renderers. Now when I run a sketch with an OpenGL renderer selected, the JVM crashes on this line of code:

if(ReflectionUtil.DEBUG_STATS_FORNAME) {

on line 210 in GLProfile.java. The included file (hs_err_pid32175.log) is the JVM crashlog. This is the message in the console:

#  SIGSEGV (0xb) at pc=0x0000000000004206, pid=32175, tid=0x00007f6c53434700
#
# JRE version: OpenJDK Runtime Environment (8.0_172) (build 1.8.0_172-solus-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.172-b00 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  0x0000000000004206

Let me know if you have any ideas. This happens whether I use the jogl-all JAR you sent, or the JAR included by Processing in gradle.

@serebit Did plain 3.3.7 work for you? Or both, 3.3.7 as well as the JAR file I posted are crashing?

@gohai Both 3.3.7 and the JAR file you posted are crashing with the same error.

@serebit And just to be sure I understand: prior to 3.3.7 you had the same issue as described in #5308 (java.lang.InternalError: XXX0 profile[1]: GL3bc -> profileImpl GL4bc !!! not mapped at )?

@gohai If I run it on 3.3.6, I get this error:

com.jogamp.opengl.GLException: Profiles [GL4bc, GL4, GL3bc, GL3, GLES3, GL2, GLES2] not available on device X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x0, owner false, ResourceToolkitLock[obj 0x458c1321, isOwner false, <11438d26, 34cd072c>[count 0, qsz 0, owner <NULL>]]]
	at com.jogamp.opengl.GLProfile.get(GLProfile.java:1039)
	at com.jogamp.opengl.GLProfile.get(GLProfile.java:1050)
	at com.jogamp.opengl.GLProfile.getMaxProgrammable(GLProfile.java:826)
	at processing.opengl.PSurfaceJOGL.initGL(PSurfaceJOGL.java:203)
	at processing.opengl.PSurfaceJOGL.initFrame(PSurfaceJOGL.java:136)
	at processing.core.PApplet.initSurface(PApplet.java:10889)
	at processing.core.PApplet.runSketch(PApplet.java:10776)
	at MainKt.main(Main.kt:4)
X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 1/1, reusable (open, marked uncloseable): 0, pending (open in creation order): 1)
X11Util: Open X11 Display Connections: 1
X11Util: Open[0]: NamedX11Display[:0, 0x7fbf58001270, refCount 1, unCloseable false]

If I run it on 3.3.7 or with the JAR you sent, I get the JVM crashlog I sent earlier.

@gohai Here's my glxinfo:
glxinfo.txt

@serebit This very much is a JOGL issue, which is a library Processing is using for OpenGL. It's unfortunate that you traded one error for another, but I don't believe there is an easy fix for that (and I am out my depth with 3D in general).

You could try filing a bug for that against JOGL's Bugzilla, but the project seems really unmaintained unfortunately. (paging @codeanticode)

Did some more digging. As it turns out, the error is somewhere in X11Display.c, in the function DispatchMessages0. Past that, I have no idea where the issue is within the function, as I don't know C and I don't know how to read memory addresses in a JVM crash dump. JOGL truly is a mess...

@gohai Correction, the jogl-all.jar produced by the master-branch Processing build does fix the issue. The only issue now is getting the remotely-hosted JOGL jars to contain the same fixes as yours, so that I don't have to store the jars locally in my projects.

@serebit Sorry, I can't follow. Can you elaborate which version is now working for you, and why this wasn't working before? Thanks.

@serebit There is no difference between the jogl library files in 3.3.7 and the ones in the master branch.

@gohai It appears that 3.3.7 in the Processing now works, somehow, as verified by downloading the editor and starting up a sketch in P3D. Consider me properly befuddled, but thankful that this nonsense has been resolved.

Nevertheless, I'd still recommend to the Processing team that they add a transitive dependency on their locally-built jogl-all files instead of the files provided by Maven Central, as the ones provided by Maven Central do not contain the mesa fixes.

The Processing project has nothing to do with whatever is up on Maven Central. Locking this thread.