Skip to content

Processing OpenGL renderer core dumping on Raspberry Pi #1087

Open
@hx2A

Description

@hx2A
Collaborator

Most appropriate sub-area of Processing 4?

Core/Environment/Rendering

Processing version

4.4.1

Operating system

Linux pihole 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux

Steps to reproduce this

  1. Install Processing on Raspberry pi 64 bit using snap, as per install instructions

  2. Run this Sketch:

void setup() {
  size(200, 200, P2D);
}

void draw() {
  rect(mouseX, mouseY, 10, 10);
}
  1. Get core dump:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000007f7c0efc5c, pid=10483, tid=10487
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.14+7 (17.0.14+7) (build 17.0.14+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.14+7 (17.0.14+7, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-aarch64)
# Problematic frame:
# C  [libnewt_head.so+0xfc5c]  Java_jogamp_newt_driver_x11_RandR13_getMonitorName0+0x9c
#
# No core dump will be written. 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/jim/hs_err_pid10483.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# 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).

snippet

void setup() {
  size(200, 200, P2D);
}

void draw() {
  rect(mouseX, mouseY, 10, 10);
}

Additional context

No response

Would you like to work on the issue?

I can help test & investigate

Activity

added
bugSomething isn't working
on May 10, 2025
hx2A

hx2A commented on May 10, 2025

@hx2A
CollaboratorAuthor

I get this same problem with py5 and while investigating I found it also happens in Processing 4.4.1 through the PDE.

I initially thought that the problem was caused by setting the native libraries incorrectly. I'd like to understand how this is done in Processing. I am less familiar with the PDE code. Ideally, py5 and Processing pick the native library directory the same way so both get the same results.

I looked in the PDE code and I found this:

private void handleNative() {

  private void handleNative() {
    String variant = Platform.getVariant();

    // use the root of the library folder as the default
    File nativeLibraryFolder = libraryFolder;

    /*
    String hostPlatform = Platform.getName();
    // see if there's a 'windows', 'macosx', or 'linux' folder
    File hostLibrary = new File(libraryFolder, hostPlatform);
    if (hostLibrary.exists()) {
      nativeLibraryFolder = hostLibrary;
    }
    */

    // see if there's a {platform}-{arch} folder
    File hostLibrary = new File(libraryFolder, variant);
    if (hostLibrary.exists()) {
      nativeLibraryFolder = hostLibrary;

    } else {
      // if not found, try the old-style naming
      String oldName = newToOld.get(variant);
      if (oldName != null) {
        hostLibrary = new File(libraryFolder, oldName);
        if (hostLibrary.exists()) {
          nativeLibraryFolder = hostLibrary;
        }
      }
    }

    // save that folder for later use
    nativeLibraryPath = nativeLibraryFolder.getAbsolutePath();
  }

Before digging deeper, am I looking in the right place?

I do know that the OpenGL native library stuff changed from how it was done in the past. Now these files are packaged up in Jars, and I note that MacOS now always uses the universal library and I see linux-arm changed to linux-armv6hf.

lib/app/resources/core/library:$ ls -1 jogl*natives*
jogl-all-2.5.0-natives-android-aarch64.jar
jogl-all-2.5.0-natives-linux-aarch64.jar
jogl-all-2.5.0-natives-linux-amd64.jar
jogl-all-2.5.0-natives-linux-armv6hf.jar
jogl-all-2.5.0-natives-macosx-universal.jar
jogl-all-2.5.0-natives-windows-amd64.jar

But that isn't relevant to the task at hand. This is 64 bit Raspberry pi, which should go to linux-aarch64, same as it was before. If I roll back to the previous native libraries, it still gives the core dump (at least it did with py5).

Stefterv

Stefterv commented on May 12, 2025

@Stefterv
Collaborator

Hi @hx2A I just tried 4.4.1 on my Raspberry pi and it works just fine.

Linux rasbian 6.6.74+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64 GNU/Linux

Looks like I might be on an older version, could you give me some more details about the install that you are using?

added this to the 4.4.5 milestone on May 12, 2025
hx2A

hx2A commented on May 12, 2025

@hx2A
CollaboratorAuthor

Linux rasbian 6.6.74+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64 GNU/Linux

Looks like I might be on an older version, could you give me some more details about the install that you are using?

Really? I would have guessed that I am on the older version. I set this up about a year ago and haven't done much with it. This raspberry pi runs pihole to block ads (which is awesome by the way, highly recommend)

To install this I used the raspberry pi image from the official website, then setup pihole with their script.

raspberry pi doesn't let you upgrade the distro through the terminal like other distros, it seems. The documentation says to create a new image on a new sd card.

Stefterv

Stefterv commented on May 12, 2025

@Stefterv
Collaborator

Okay I'll create fresh SD and install pi hole as test. Do you know which Raspi you have? I have 3b,4b and 5 and tested on 5 earlier

hx2A

hx2A commented on May 12, 2025

@hx2A
CollaboratorAuthor

Okay I'll create fresh SD and install pi hole as test. Do you know which Raspi you have? I have 3b,4b and 5 and tested on 5 earlier

I tested on a 3B, which has the hardware floating point and (I believe) should be fine with the OpenGL native libraries armv6hf.

Stefterv

Stefterv commented on May 12, 2025

@Stefterv
Collaborator

Okay I'll test on 4 and 3 too then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinglinux

    Type

    No type

    Projects

    Status

    No status

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @SableRaf@hx2A@Stefterv

        Issue actions

          Processing OpenGL renderer core dumping on Raspberry Pi · Issue #1087 · processing/processing4