I tested this on the same machine but in a Windows 2K boot, and it doesn’t crash. Therefore, it must be a linux specific bug. Has anyone tested this on a RedHat 8 box? I’d be curious to know if this is because I’m running RedHat 9.
I have rh8 and the bug isn’t there. However another mysterious one is - if you restart the display (with ‘w’ or ‘f’) 20-30 times in a row the app crashes bc. a GLX context cannot be created. Along with the exception, this is printed (from the nvidia drivers?):
hint: there may be a ulimit restricting the amount of
virtual memory available to XFree86. It may be a good
idea to check your startup scripts for something like
ulimit -v <number>
and either boost this value or remove the line.
indicating that there’s some kind of memory leak in the code.
Because I couldn’t find the leak I tried quake 3 - and surprise surprise - the same behaviour! I did a lot of vid_restart in the console and it crashes with the exact same error.
Regarding the rh 9 bug - I had stability problems with the newer glibc from an rh8 up2date, so there might be some weird jdk<->glibc interaction that triggers the error. As soon as I pull myself together and install it I will build a rh 9 version to rule out the issues Matzon mentioned.
- elias
Update: I finally got around to installing rh 9 and yes, lwjgl apps crashes after a few ‘w’ or ‘f’ key presses, failing to load GL libs. And like the last time, I tried quake3 again, with exactly the same behaviour again! Quake3 crashes after two vid_restart, and the lwjgl test crashes after two presses on ‘w’.
The detailed error from dlopen() is this one:
/usr/lib/tls/libGL.so.1: shared object cannot be dlopen()ed: static TLS memory too small
Indicating som leak in the TLS memory (Thread Local Storage?). So, I’m at a bit of a loss here as to how to fix it. I’m not happy about the fact that quake3 crashes with the same error, ruling out bad interaction between the jvm and native libs.
- elias