OpenGL sketches crash on the aarch64 (Apple Silicon) version

Created by: benfry

From the release notes for 4.0 beta 4:

Against my better judgement, I'm posting a release that's native for Apple Silicon. OpenGL is currently broken. Sketches crash immediately. You should only use it if you're a masochist. Or a masochist that likes extremely fast but very incomplete software, and won't file bug reports saying “OpenGL is broken.” But it's being posted for folks who do not need OpenGL, and/or want to help debug.

This may simply be due to #284 which itself may be a known upstream bug: TheInfiniteKind/appbundler#70

Created by: jaegonlee

I tested some jogl examples, they works ok except using newt. It crashes when creating GLWindow.

Code terminated in next step

.

Created by: benfry

Thanks for looking into it, good to know… That could be a problem in the JOGL build that I made not properly supporting NEWT. Which could be good news in some ways (maybe I did something dumb), or bad news in others (NEWT may need more complicated changes for aarch64).

Created by: benfry

Confirming the crash inside NEWT for us (this is jdb output of running an exported application).

Step completed: "thread=main", jogamp.newt.WindowImpl.<clinit>(), line=204 bci=57

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=67 bci=0

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.DisplayDriver.initSingleton(), line=102 bci=0

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=68 bci=3

main[1] step
> 
The application has been disconnected

That's inside PSurfaceJOGL.initDisplay(), though it only got that far after disabling the earlier NewtFactory.setWindowIcons(res) call, which I was hoping was just happening at the wrong time.

Created by: benfry

Though perhaps interestingly, setWindowIcons() only does an assignment:

  public static void setWindowIcons(ClassResources var0) {
    defaultWindowIcons = var0;
  }

…so it seems there's something in the static initialization of the NEWT code that's causing trouble. Which also means it could be pretty early in loading the native library.

Created by: benfry

The aarch64 JOGL builds were done with these instructions: https://github.com/jzy3d/jogl/blob/feature/macosx-arm64/HOW-TO-ADD-ARM64-TO-2.4.md

And the result of that is also in a Maven repository:

However, swapping these in still leaves a crash in the same place when initializing a Processing sketch. I'd have to check whether it's the same for NEWT demos.

@codeanticode

Created by: benfry

Ok, and confirming that the NEWT demos crash the same way, using my build and the jzy3d builds.

Start the debugger:

jdb -classpath \
  gluegen-rt.jar:gluegen-test-util.jar:jogl-all.jar:jogl-test.jar:junit.jar \
  com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT

Commands given to the debugger:

stop in jogamp.newt.driver.macosx.DisplayDriver.initSingleton
step
step

And finally:

Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=68 bci=3

…as the last line before the crash.

Or for the full trace:

Initializing jdb ...
> stop in jogamp.newt.driver.macosx.DisplayDriver.initSingleton
Deferring breakpoint jogamp.newt.driver.macosx.DisplayDriver.initSingleton.
It will be set after the class is loaded.
> run
run com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
> 
VM Started: position null
size 640 x 480
resize null
screen 0
translucent false
forceAlpha -1
undecorated false
atop false
abottom false
resizable true
sticky false
max_vert false
max_horz false
fullscreen false
mouseVisible true
mouseConfined false
pointerIcon false
loops 1
loop shutdown false
forceES2 false
forceES3 false
forceGL3 false
forceGL2 false
forceDebug false
forceTrace false
swapInterval 1
exclusiveContext false
useAnimator true
sysExitWithin none
mappedBuffers false
demoType 1
traceMouse false
JUnit version 4.8.2
++++ Test Singleton.ctor()
++++ Test Singleton.lock()
SLOCK [T SingletonServerSocket1-localhost/127.0.0.1:59999 @ 1643513410004 ms III - Start
SLOCK [T main @ 1643513410005 ms +++ localhost/127.0.0.1:59999 - Locked within 9 ms, 1 attempts
.++++ TestCase.setUp: com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT - test03_GL3
requested: vsync 1, GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono  , hw, GLProfile[GL3/GL4.hw], on-scr[.]]
Set deferred breakpoint jogamp.newt.driver.macosx.DisplayDriver.initSingleton

Breakpoint hit: "thread=main", jogamp.newt.driver.macosx.DisplayDriver.initSingleton(), line=102 bci=0

main[1] step
> 
Step completed: "thread=main", jogamp.newt.driver.macosx.WindowDriver.<clinit>(), line=68 bci=3

main[1] step
> 
The application has been disconnected

also CCing @codeanticode for the progress update…

Created by: benfry

Oh, and when run with appbundler, we get the full macOS crash thing, with this possible clue in the details:

Application Specific Information:
-[NSOpenGLContext update] must be called from the main thread if the context has a view.

Created by: jaegonlee

Adding 2 lines of codes, it works with Jogl Newt Example.
(I don't know why)

MacNewtNSWindow.m(jogl/src/newt/native)
return NULL;

MacWindow.m(jogl/src/newt/native)
sleep(1);

OpenGL sketchs are running, but can't draw anything.

Created by: jaegonlee

OpenGL sketches works fine after short delay.

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

void draw() {
  if (frameCount > 1) {
    // draw something
    background(0);
    ellipse(200, 200, 100, 100);
  }
}

Created by: benfry

Sounds like good progress! Though fragile :)

Created by: benfry

Hm, also seeing similar framebuffer errors when running the Intel version on an M1 Max:

OpenGL error 1286 at top beginDraw(): invalid framebuffer operation
OpenGL error 1286 at bot beginDraw(): invalid framebuffer operation

@jaegonlee

Created by: benfry

@jaegonlee Does the sleep() hack work consistently for you? I'm starting to wonder whether we want to just go with the hack for now (so that it's not just crashing for folks) until someone has the time or wherewithal to fix it properly.

@benfry

Created by: jaegonlee

@benfry some errors occur (as you mentioned above) when launching, but codes are running without problems.
(except resizing window)

OpenGL error 1286 at top beginDraw(): invalid framebuffer operation
OpenGL error 1286 at bot beginDraw(): invalid framebuffer operation
OpenGL error 1286 at bot endDraw(): invalid framebuffer operation

Created by: benfry

And I'm guessing keys are disabled as well (or at least keys that aren't just a-z and 0-9) because it's skipping the function to set up the mappings?

Created by: jaegonlee

Calling TISGetInputSourceProperty() to get keyboard layout cause the crash.
Instead of adding return NULL; to pass it, addiing dispatch_async could avoid the crash when mapping the keys.

MacNewtNSWindow.m(jogl/src/newt/native)

dispatch_async(dispatch_get_main_queue(), ^(){ 
    CKCH_CreateDictionaries(); 
});

key mapping is ok now.

Created by: jaegonlee

I could fix the problem with newt window.
-[NSOpenGLContext update] must be called from the main thread if the context has a view. golang/go#35177 (comment)

MacOSXWindowSystemInterface.m(jogl/src/jogl/native/macosx/)

void updateContext(NSOpenGLContext* ctx) {
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
  NSView *nsView = [ctx view];
  if(NULL != nsView) {
      DBG_PRINT("updateContext.0: ctx %p, ctx.view %p\n", ctx, nsView);
      // [ctx update]; from 
      [ctx performSelectorOnMainThread:@selector(update) withObject:nil waitUntilDone:NO]; // to 

      DBG_PRINT("updateContext.X\n");
  }
  [pool release];
}

no need to sleep(1) or delay, and there're no more framebuffer errors.

Created by: benfry

Fantastic! This is exactly what we're looking for. I'll take a look at patching that up and if it works, maybe we'll push out a new beta. This would be huge!

@jaegonlee

Created by: codeanticode

Nice, I have been following this issue looks you have made great progress. Thanks a lot @jaegonlee !!

@jaegonlee

Created by: benfry

Ok, with the help of @jaegonlee's patches:

…I was able to hack together a working JOGL for ARM for 4.0 beta 8. 🎉

Created by: benfry

To build from an (already existing) git clone, you'll need to clear out the old JOGL libraries:

cd /path/to/processing4/core
ant clean-jogl

then do a fresh build:

cd ../build
ant run

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.

Navigation Menu

Repository navigation

OpenGL sketches crash on the `aarch64` (Apple Silicon) version #370

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OpenGL sketches crash on the aarch64 (Apple Silicon) version #370

Description

Activity

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Jan 30, 2022

processing-bot commented on Feb 16, 2022

processing-bot commented on Feb 18, 2022

processing-bot commented on Feb 19, 2022

processing-bot commented on Feb 19, 2022

processing-bot commented on Feb 21, 2022

processing-bot commented on Feb 21, 2022

processing-bot commented on Feb 21, 2022

processing-bot commented on Feb 21, 2022

processing-bot commented on Apr 23, 2022

processing-bot commented on Apr 23, 2022

processing-bot commented on May 24, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

OpenGL sketches crash on the `aarch64` (Apple Silicon) version #370