"An unrecoverable stack overflow has occurred."

[Orangy Tang]

Has anyone seen this before? I've got a lwjgl app occasionally dies with this error (note this is *not* a StackOverflowException, it seems to be some kind of low-level error which kills the vm).

The setup is that I've got a Minecraft map renderer, and a minecraft server wrapper. Most of the time this work, but on one machine the map renderer triggers this error. And it *only* happens when run as a child process of the server wrapper - running it standalone works just fine. The whole setup works just fine on my mac laptop as well, it just seems to be this particular machine.

It occurs both on the 1.6.18 VM and the latest 1.6.22 VM.

Has anyone got any hints as to what this might be, and what to do to debug it?

Thanks

[Riven]

Try to create your thread with a larger stacksize:
     new Thread(..., ..., ..., 4*1024*1024)
or
     -XX:ThreadStackSize=4M
to see if that makes a difference.

[Orangy Tang]

Hmm, I didn't know about that XX option, I'll give it a go, thanks.

I'm still none the wiser as to why it would fail when launched via ProcessBuilder vs. from a command line though. I'm going to try and add a bunch of logging to try and track it down to a particular function.

Games published by our own members! Check 'em out!

[Riven]

Actually, the parameters seems to be in K

So you'd have to pass:
  -XX:ThreadStackSize=4096
for 4M stack (1M is the default)

[Orangy Tang]

This gets odder. Trying to increase the stack size with that command doesn't help, it still bombs out the same way (without even one of those raw access violation hs_err_pidXXX.log files).

If I remove the other options to manually increase the heap and direct buffer memory, then it seems to work. Of course now my app dies with an out-of-direct-memory exception because I'm loading so much geometry.

Obviously I'm going to have to do something smarter with my geometry caching. Does anyone know a way to query available/allocated/total direct memory at runtime? I'm assuming the Runtime memory queries are for the regular heap only.

[Riven]

I'm assuming the Runtime memory queries are for the regular heap only.

Correct.

Does anyone know a way to query available/allocated/total direct memory at runtime? I'm assuming the Runtime memory queries are for the regular heap only.

IIRC those values are stored in sun.misc.Bits

[Orangy Tang]

I found sun.misc.VM.maxDirectMemory(), which returns a surprising 2Gb (!), but that's on this 64bit Win7 machine, which is not the one with the issue (which is running 32bit XP).

I may try the old-school approach of just allocating as much direct memory as possible up front until an exception is thrown, then doing my own memory management.

[Riven]

Set a reasonable max though. Nothing worse than to starve other processes from address space.