Hello.
I am encountering an exception access violation when loading image resources with org.lwjgl.stb.STBImage.stbi_load_from_memory. I have copied ioResourceToByteBuffer from lwjgl3-demos/src/org/lwjgl/demo/util/IOUtils.java into my project and am using it as the ByteBuffer input for stbi_load_from_memory. I have attached the crash report.
As far as I can tell, I am using ioResourceToByteBuffer in the same way as demonstrated in the lwjgl3 demos, but I am calling it from multiple threads. There does not seem to be a pattern to when the crash occurs. Are there any synchronization issues or limitations for ioResourceToByteBuffer or stbi_load_from_memory?
I was not able to attach the crash report (maybe because of size). Here is the first portion:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb47a560cc, pid=7056, tid=10020
#
# JRE version: Java(TM) SE Runtime Environment (16.0.1+9) (build 16.0.1+9-24)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0.1+9-24, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C [lwjgl_stb.dll+0x60cc]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
# https://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.
#
--------------- S U M M A R Y ------------
Command Line: -Dfile.encoding=Cp1252 -XX:+ShowCodeDetailsInExceptionMessages game.Game
Host: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 12 cores, 31G, Windows 10 , 64 bit Build 19041 (10.0.19041.1806)
Time: Sat Aug 6 21:29:38 2022 Central Daylight Time elapsed time: 321.448003 seconds (0d 0h 5m 21s)
--------------- T H R E A D ---------------
Current thread (0x000001ee1e5f7900): JavaThread "Thread-3280" [_thread_in_native, id=10020, stack(0x000000a711c00000,0x000000a711d00000)]
Stack: [0x000000a711c00000,0x000000a711d00000], sp=0x000000a711cfdc20, free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [lwjgl_stb.dll+0x60cc]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 1673 org.lwjgl.stb.STBImage.nstbi_load_from_memory(JIJJJI)J (0 bytes) @ 0x000001eda4ede58b [0x000001eda4ede520+0x000000000000006b]
J 2976 c2 org.lwjgl.stb.STBImage.stbi_load_from_memory(Ljava/nio/ByteBuffer;Ljava/nio/IntBuffer;Ljava/nio/IntBuffer;Ljava/nio/IntBuffer;I)Ljava/nio/ByteBuffer; (90 bytes) @ 0x000001eda503523c [0x000001eda5035160+0x00000000000000dc]
J 2222 c1 utilities.ResourceReader.readImageRGBA()V (199 bytes) @ 0x000001ed9dc99354 [0x000001ed9dc98b60+0x00000000000007f4]
J 1714 c1 utilities.ResourceReader.run()V (40 bytes) @ 0x000001ed9dbc67ec [0x000001ed9dbc66e0+0x000000000000010c]
v ~StubRoutines::call_stub
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x000001ee100385c9
My usage looks something like this:
public void run() {
switch(resourceType) {
case RESOURCE_TYPE_IMAGE_RGBA:
readImageRGBA();
break;
case RESOURCE_TYPE_AUDIO_STREAM:
readAudioStream();
default:
break;
}
}
private void readImageRGBA() {
RGBAResource[] resources = new RGBAResource[resourcePaths.length];
for(int i = 0; i < resourcePaths.length; i++) {
try(MemoryStack stack = MemoryStack.stackPush()) {
IntBuffer pWidth = stack.mallocInt(1);
IntBuffer pHeight = stack.mallocInt(1);
IntBuffer pChannels = stack.mallocInt(1);
ByteBuffer imageRGBA = stbi_load_from_memory(ioResourceToByteBuffer(resourcePaths, RESOURCE_TO_BYTE_BUFFER_DEFAULT_SIZE),
pWidth,
pHeight,
pChannels,
STBI_rgb_alpha);
resources = new RGBAResource(pHeight.get(0), pWidth.get(0), imageRGBA);
} catch (Exception e) {
e.printStackTrace();
}
}
requester.requestedImageRGBACallback(resourceId, resources);
}
Where these methods' class extends Thread.
I can use stbi_load_from_memory from a single thread, but my load times are 2-3 times longer. Alternatively, stbi_load can be called from multiple threads without issue.