Unexpected OutOfMemoryError...

Thu Nov 30 12:50:00 GMT 2006

gabriel.bianco@pixeon.com.br writes:
 > Citando Andrew Haley <aph@redhat.com>:
 > > I can't reproduce this. I guess it's probably a Windows-specific thing.
 > > 
 > > The gc calls either VirtualAlloc or GlobalAlloc, depending on how it
 > > is configured. If either of these fails, the full error information
 > > may be retrieved by calling GetLastError.
 > > 
 > > If I were you, I'd go into os_dep.c and add a bunch of trace
 > > information to GC_win32_get_mem to see why the gc is failing to
 > > allocate memory.
 > 
 > Took me a while, but I finally learned how to compile it... But it didn't show
 > anything interesting, no errors.
 > 
 > I've attached the output of the test, but the error doesn't seem to be in
 > GC_win32_get_mem(). It calls VirtualAlloc(), but never fails...
 > 
 > It only calls GC_win32_get_mem() a few times. The OutOfMemoryError exception is
 > thrown from somewhere else.
Ah, now, that is _very_ interesting. The gc calls GC_oom_fn, which
points to out_of_memory in libjava/boehm.cc:
static void * handle_out_of_memory(size_t)
{
 _Jv_ThrowNoMemory();
}
Note that the size_t parameter is interesting: it tells you how big
the failing memory request was. It would be good to print that. If
you have gdb, you can put a breakpoint on handle_out_of_memory.
Also, see doc/README.environment:
GC_PRINT_STATS - Turn on as much logging as is easily feasible without
		 adding signifcant runtime overhead. Doesn't work if
		 the collector is built with SMALL_CONFIG. Overridden
		 by setting GC_quiet. On by default if the collector
		 was built without -DSILENT.
Andrew.