P2D P3D causing core dump

Running Linux Mint 20.1 with latest proprietary NVIDIA drivers, Processing 3.5.4.

I have installed Processing just by unpacking the tgz and running it. Any sketch that tries to use the openGL P2D or P3D modes causes a core dump:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f9d801bda2a, pid=15265, tid=0x00007f9d6cec4700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_202-b08) (build 1.8.0_202-b08)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [i965_dri.so+0x147a2a]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/roba/processing-3.5.4/hs_err_pid15265.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Could not run the sketch (Target VM failed to initialize).
For more information, read revisions.txt and Help → Troubleshooting.

I switched to this version in order to get the sound libraries working Other Post Here.
I reinstalled the Flatpak version and it is able to use P2D and P3D perfectly fine - so I am assuming this is not a driver issue… but could be completely wrong (maybe Flatpak provide its own drivers?)

SO I have a choice of running the Flatpack version to be able to us openG but have no access to the sound libraries, ot the “normal” version to use sound but then can’t use openGL… So Frustrating!!!

Any suggestions where to go from here?

Thanks in advance -

-Rob A>

Are you using a system with dual graphics; an integrated Intel GPU and an NVIDIA GPU?

Clutching at straws guessing all works fine on my linux box. Is there perhaps some residual configuration from Flatpack? Where does jogamp temporary files get written on your system, default is /tmp but you are able to specify a different folder by passing flags to jvm. Anyway basically you need permission to write to a temporary cache for jogamp/opengl to work.

Yes - it is a laptop with dual graphics (ASUS X550L).

-Rob A>

I don’t know if you can try forcing it to run sketches with the NVIDIA card. It must be running them using the Intel based on that error log (i965_dri.so).

On my system (Ubuntu 20.04 with Intel graphics), Processing 3.x recently started failing to draw stuff (although it doesn’t crash). Maybe it doesn’t work well with the latest Intel drivers. I tried to run Linux on a laptop with dual graphics in the past and I remember it being a pain.

Thanks - I’ve reas the dual video can be problematic. I’ll try uninstalling the NVIDIA drivers a go back to neuveau to see if it helps.

The frustrating thing is that it works with the flatpak version but not the regular version! What gets even weirder is that if I drill into the flatpak location and run processing from that location using the flatpak included version of java, it also coredumps with openGL. Yet if I run the exact same version via the flatpak binary it does NOT coredump (but audio libraries fail to work)… GRRRR

-Rob A.

OK-

I finally have a working solution, so I’ll post here for posterity and case anyone searches.

After playing with “alternates” and installing different version of JAVA, symlinking to different and on and on, ended up abandoning trying to get the version downloaded from Download \ Processing.org to actually work with openGL on my system.

Instead, as the flatpack version Flathub—An app store and build service for Linux was running fine without core-dumping, I went back to try an solve my prior issue of getting sound to work…

Digging into Flatpak I discovered this gem:
https://docs.flatpak.org/en/latest/sandbox-permissions.html#standard-permissions

Standard permissions

The following permissions provide access to basic resources that applications commonly require, and can therefore be freely used:

  • --socket=pulseaudio - play sound with PulseAudio

So ask ask myself… “self - what are the sandbox permissions of the org.processing.processingide flatpak?? Is it possible the packager forgot to give permissions to access pulseaudio?”

Long story short - yes - the packager didn’t set the sandbox permissions correctly.

I ended up installing this handy tool (also a flatpak) that lets you view and change flatpak sandbox permissions: How To Easily Configure Flatpak Apps Permissions With Flatseal

Two minutes later I checked the settings and toggled access to pulseaudio, now sound works.

-Rob A>