low memory problems (causes a crash)

Hey there,

we've seen a crash in nvd3dum.dll on a particular PC. After DebugGL it is clear that there is an uncatched native OutOfMemoryError. The software runs some times at the edge of the 32 bit memory area. That means there is no native memory left for Threads, windows and so on. We've handled them all to ensure software stability. Unfortunately, jogl doesn't expose the excpection in standard mode but it carshes somewhere deep in nvd3dum.dll when openeing a new window. I think this behaviour is just a driver issue with other graphics cards it is probably handled better and there are just graphics artefacts.


I don't really like to use DebugGL in release mode. Is there another option to force jogl to throw exceptions in low memory circumstances?

kind regards
Matthias

You can put a switch into your software so that the end user can run it with DebugGL only when it is required. It's up to the developer to manage native memory, the JVM doesn't do it for you except if it might run out of memory on the Java heap. Do you create a lot of windows?

well, not really. There is actually just one external window created and I have three (okay now four) contexts. The problem is, in case I am running on 32 bit with Xmx1024M we only have 512MB left for entire 32 bit software programs. That means if there is something running pretty big I am getting very fast to a low memory problem.

I can handle java heap insuffictency and I can handle native memory allocation problems in my own native code as well. This is not problem. But jogl doesn't handle it seems it relies on the driver and in my case the Nvidia driver crashed ;)

Having an DebugGL option is not really an option since the crash happens and the user gets frustated. How does he know he should start with DebugGL? We are in end-consumer range products, so it is not easy to explain what happens here and it is nearly impossible to write it in a documentation ;)

If you want us to improve something, please provide a test case. I still have a 32 bits machine with an old ATI graphics card, maybe someone else has a machine closer to your expectations. Maybe we can reproduce your case by lowering the memory on the native heap, it's just a supposition.

well, I am also stuck to 32 bits :) That mean we can only use until 1536MB java heap. Normally I can only use 1024MB. 1536M doesn't initialize the JRE due to a 32-bit adress space lag. That mean that native heap is also pretty close to low memory. I am not sure how to build a test case for this ;)


I would have to eat up almost the entire native heap. Probably init JRE with 1024MB and after that through JNI I would have to allocate hundreds of megabytes by small portions of let's say 8MB until I get an malloc/new error. After that I have the situation where no memory is left for OpenGL/JOGL native calls.

Any ideas how to put it in a good JUnit test?

Why not using a smaller Java heap and a smaller native heap to reproduce this bug faster?