macOS Apple Silicon bug - [libGLImage.dylib+0x1de2c] storeVecColor_RGBA_UI+0x40

Hi support,

I want to report a serious issue with JOGL on macOS Apple Silicon using JOGL 2.5.0 released on 2023-08-18. The error is confirmed to happen with all JDKs 17 to 21, both Oracle JDK and also GraalVM JDK. I have not tested with older JDKs.

We know that the issue is specifically related to macOS Apple Silicon, because it does not occur on macOS intel, nor on Windows, nor Linux.

Our application is an image processing application, and we load images as 1 big texture at the moment to view them visually, provided that the reported image texture size is big enough, otherwise we fall back to a CPU image viewer.

We get consistent crashes on Apple Silicon if we load an image with dimensions of roughly 13000x12000 pixels. With smaller images all is fine. All bigger images will crash in the same way.

The error that we see on system out is:

[thread 22275 also had an error][thread 115519 also had an error]
#

[thread 102699 also had an error][thread 93207 also had an error]

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000001f561ae2c, pid=1377, tid=45827
#
# JRE version: Java(TM) SE Runtime Environment Oracle GraalVM 21.0.2+13.1 (21.0.2+13) (build 21.0.2+13-LTS-jvmci-23.1-b30)
# Java VM: Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 21.0.2+13.1 (21.0.2+13-LTS-jvmci-23.1-b30, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# [thread 95235 also had an error]
[thread 173863 also had an error]
[thread 107019 also had an error]
[thread 107291 also had an error]
[thread 103259 also had an error]
[thread 124207 also had an error]
[thread 123911 also had an error]
C  [libGLImage.dylib+0x1de2c]  storeVecColor_RGBA_UI+0x40
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
[thread 102923 also had an error]
[thread 110299 also had an error]
[thread 99359 also had an error]
[thread 173391 also had an error]
# An error report file with more information is saved as:
# /Users/mabula/IdeaProjects/astropixelprocessor-jdk17/hs_err_pid1377.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#


So it seems that the error might occur in C  [libGLImage.dylib+0x1de2c]  storeVecColor_RGBA_UI+0x40

macOS reports this, thread crashing is Crashed Thread: 47 Dispatch queue: GLImageWork:

"Process: java [26857]
Path: /Applications/AstroPixelProcessor.app/Contents/MacOS/
universalJavaApplicationStub
Identifier: java
Version: ???
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2023-06-14 13:22:54.7681 -0700
OS Version: macOS 13.4 (22F66)
Report Version: 12
Anonymous UUID: C22A1F61-83E1-B9CD-3580-041C170F34EB
Sleep/Wake UUID: B34BF2F5-BE15-48EC-8B15-1641ADF6D333
Time Awake Since Boot: 120000 seconds
Time Since Wake: 5138 seconds
System Integrity Protection: enabled
Crashed Thread: 47 Dispatch queue: GLImageWork
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000
VM Region Info: 0 is not in any region. Bytes before following region: 4334796800
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD
REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 1025fc000-102600000 [ 16K] r-x/r-x
SM=COW ...Home/bin/java"


My first question is if this issue is known already or if you need more information from me to get this solved?
I think the crashes will occur if the texture size is bigger than a certain threshold, which I will try to determine in the meantime.

Some more info on this: it happens only with a color texture, so if I texturize a monochrome image of such size 12000x12000 pixels, it does work.

I have tested with OpenGL2 and OpenGL4 and the error is the same

We try to create a texture with

internalformat = GL.GL_RGB
pixelformat = Gl.GL_RGB
pixeltype = GL.GL_FLOAT

so it concerns 32bits FLOAT RGB images.

The error happens with this call in our display( GLAutoDrawable glautodrawable ) method:

 gl4.glTexImage2D(GL.GL_TEXTURE_2D, 0, internalFormat, textureWidth, textureHeight, 0, pixelFormat, pixelType, pixels);

And this is from the hs_err_pidxxxx.log

Stack: [0x00000002c9ec4000,0x00000002c9f47000],  sp=0x00000002c9f46930,  free space=522k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libGLImage.dylib+0x1de2c]  storeVecColor_RGBA_UI+0x40
C  [libGLImage.dylib+0x6bd4]  __glgProcessPixelsWithProcessor_block_invoke+0x94
C  [libdispatch.dylib+0x1cb8]  _dispatch_call_block_and_release+0x20
C  [libdispatch.dylib+0x3910]  _dispatch_client_callout+0x14
C  [libdispatch.dylib+0x6e4c]  _dispatch_continuation_pop+0x2dc
C  [libdispatch.dylib+0x6478]  _dispatch_async_redirect_invoke+0x2dc
C  [libdispatch.dylib+0x151f4]  _dispatch_root_queue_drain+0x188
C  [libdispatch.dylib+0x15a04]  _dispatch_worker_thread2+0x9c
C  [libsystem_pthread.dylib+0x30d8]  _pthread_wqthread+0xe4

To me this seams that there is a bug clearly, we need to use Gl.GL_RGB for internalformat and pixelformat with datatype float and in the error that is thrown, it seams like RGBA is used which obviously will not work?

I also tried to use GL_RGB32F for the internalformat, with no change in outcome.

WHOOPS, this calculation is nor correct so please disregard this calculation in this post, below I have posted in a new post the correct calculation.
===============NOT CORRECT=====================================

I have done more testing and  I have found the threshold image size on which this error will occur only on Apple Silicon macs.
If the image dimensions = dim_x * dim_y  
multiplied with the number of bytes for the float data  = *4
exceeds a size of 512MB where 1MB = 1024x1024 Bytes
the crash occurs...

So
an image of size 14145x9430 will load    total pixels = 133.387.350 pixels -> bytes ? * 4 = 533.549.400 bytes
an image of size 14196x9464 will not...  total pixels = 134.350.944 pixels -> bytes ? * 4 = 537.403.776 bytes

512MB = 1024*1024*512 bytes = 536870912

Maybe the error occurs due to the size of the FloatBuffer ?
Is it known that this buffer is not allowed to exceed this size on Apple Silicon macs?

===============NOT CORRECT=====================================

What is the value of GL_MAX_TEXTURE_SIZE?

Do you use -XX:MaxDirectMemorySize and -Xmx?

By the way, even a very old iPhone should support such texture sizes.

first off, if a native OS library crashes instead of simply reporting an error, it is NOT JOGL/JogAmp's fault as such behavior is not acceptable (-> Apple's libGLImage).

looks like they have issues accepting the float format for the pixelformat ..

Hi,

The Gl_MAX_TEXTURE_SIZE value on my mac-mini M1 where I have the issue is = 16384

I do not use -XX:MaxDirectMemorySize
I also do not use -XmX, but rather -XX:MaxRAMPercentage=95.
The systems on which the problem occur have at least 16GB of RAM, plenty for such large images.

The vmargs that we use are

-XX:+UseJVMCICompiler -XX:+EagerJVMCI -Dgraal.CompilerConfiguration=enterprise -Dgraal.UsePriorityInlining=false -XX:+UseG1GC -XX:G1PeriodicGCInterval=3000 -XX:MaxGCPauseMillis=500 -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=70 -XX:-ShrinkHeapInSteps -XX:MaxRAMPercentage=95 -Xss1024k -XX:+DisableExplicitGC -Xms512m -Dfile.encoding=UTF-8 -Dsun.java2d.d3d=false -Dsun.java2d.opengl=false -Dsun.java2d.noddraw=true -Dsun.awt.noerasebackground=true -Dsun.java2d.metal=false --add-exports java.base/java.lang=ALL-UNNAMED --add-exports java.desktop/sun.awt=ALL-UNNAMED --add-exports java.desktop/sun.java2d=ALL-UNNAMED -Djogamp.gluegen.UseTempJarCache=false

"By the way, even a very old iPhone should support such texture sizes. "
I understand,  so the bug is not nice especiially when it happens only on Apple Silicon macs.. :-( (not the first time that Apple gives me headaches... )

"first off, if a native OS library crashes instead of simply reporting an error, it is NOT JOGL/JogAmp's fault as such behavior is not acceptable (-> Apple's libGLImage).

looks like they have issues accepting the float format for the pixelformat .. "

Okay, I totally agree with you here. I did not realize that libGLImage is a native OS lib.

So, this really points then to a bug in their Apple Silicon code for GL ?
The error has been there for quite a while, it was alreay happening with Apple Silicon macs with Big Sur and still now on Sonoma.

The float format is not the issue, a monochrome float 32bit image will load without issues, but not the RGB 32 bit float.
I will try to see what happens if I load a monochrome 32bit image that also exceeds that threshold of 512MB  for the buffer, did not try it yet.

So a monochrome float image of 15000x15000 does work, whereas a 15000x15000 RGB float image does not.

Our software processes astronomical images and we use 32bits float data all the time and have been doing this for years with JOGL and java ;-)

How to proceed to get this solved? Should i report this problem to Apple now?

Please disregard the calculation that I posted earlier, I took not into account that it was for images with 3 channels.

Below you will find the correct calculation:

-> I have found the threshold image size on which this error will occur only on Apple Silicon macs.
If the image dimensions = dim_x * dim_y  
multiplied with the number of bytes for the float data  = *4
multiplied with the number of channels (1 mono, 3 RGB)
exceeds a size of 1536MB where 1MB = 1024x1024 Bytes
the crash occurs...


So
an image of size 14145x9430 with 3 channels will load, total pixels = 133.387.350 pixels -> bytes ? * 4 * 3 channels RGB= 3 * 1.600.648.200 bytes
an image of size 14196x9464 with 3 channels will not...  total pixels = 134.350.944 pixels -> bytes ? * 4 * 3 channels RGB= 3 * 1.612.211.328 bytes

1536MB = 1024*1024*512*3 bytes = 1.610.612.736 bytes

The size of the float buffer clearly is not the issue, the buffer is created correctly and has the correct size when i try to create the texture.

Why not removing JOGL from the equation by writing a reproducer in C and filling a bug report against Apple GL library?