[Gc] Out of Memory! Returning NIL!

Simon Tsai mtsai at adobe.com
Wed Nov 15 17:05:47 PST 2006


>>"Thread stack pointer out of range"
Our program has ~70 threads running. I have checked the stack pointer
could be in another thread stack pointer range (not sure). Does this
cause problems?

>> The collection numbers are not monotonically increasing, the heap
size
suddenly jumps without indication of heap expansion.

Which data to check? I cannot find the data you are talking about? Which
function I should set breakpoint?

Please review the attached gc.log.

Thanks,

simon


-----Original Message-----
From: Boehm, Hans [mailto:hans.boehm at hp.com] 
Sent: Tuesday, November 14, 2006 5:59 PM
To: Simon Tsai
Cc: gc at napali.hpl.hp.com
Subject: RE: [Gc] Out of Memory! Returning NIL!

The log (not posted due to size) starts to look very problematic around
here:

--> Marking for collection 6 after 0 allocd bytes + 0 wasted bytes
Collection 5 reclaimed 0 bytes ---> heapsize = 1458176 bytes
World-stopped marking took 16 msecs
Bytes recovered before sweep - f.l. count = 0
Immediately reclaimed 0 bytes in heap of size 1458176 bytes(0 unmapped)
0 (atomic) + 112396 (composite) collectable bytes in use
Finalize + initiate sweep took 0 + 0 msecs
Complete collection took 16 msecs
Initiating full world-stop collection 7 after 0 allocd bytes
0 bytes in heap blacklisted for interior pointers
--> Marking for collection 7 after 0 allocd bytes + 0 wasted bytes
Collection 6 reclaimed 0 bytes ---> heapsize = 1458176 bytes
World-stopped marking took 15 msecs
Bytes recovered before sweep - f.l. count = 0
Immediately reclaimed 0 bytes in heap of size 1458176 bytes(0 unmapped)
0 (atomic) + 112396 (composite) collectable bytes in use
Finalize + initiate sweep took 0 + 0 msecs
Complete collection took 31 msecs
Initiating full world-stop collection 8 after 0 allocd bytes
0 bytes in heap blacklisted for interior pointers
--> Marking for collection 8 after 0 allocd bytes + 0 wasted bytes
Collection 7 reclaimed 0 bytes ---> heapsize = 1458176 bytes
World-stopped marking took 31 msecs
Bytes recovered before sweep - f.l. count = 0
ImmediatIncreasing heap size by 11304960 after 44256456 allocated bytes
Initiating full world-stop collection 7 after 46145016 allocd bytes
8192 bytes in heap blacklisted for interior pointers
--> Marking for collection 7 after 46145016 allocd bytes + 4291876
wasted bytes
Found new system malloc AllocationBase at 0x6a00000
GC Warning: Thread stack pointer 0x5e5fe60 out of range, pushing
everything
Collection 6 reclaimed 44248 bytes ---> heapsize = 45211648 bytes
World-stopped marking took 235 msecs
Bytes recovered before sweep - f.l. count = -151092
Immediately reclaimed -151092 bytes in heap of size 45211648 bytes(0
unmapped)
0 (atomic) + 3415544 (composite) collectable bytes in use
Finalize + initiate sweep took 0 + 0 msecs
Complete collection took 235 msecs
Initiating full world-stop collection 8 after 39636 allocd bytes
8241152 bytes in heap blacklisted for interior pointers
--> Marking for collection 8 after 39636 allocd bytes + 4092 wasted
bytes
GC Warning: Thread stack pointer 0x5e5fe60 out of range, pushing
everything
Collection 7 reclaimed -132308 bytes ---> heapsize = 45211648 bytes
World-stopped marking took 141 msecs
Bytes recovered before sweep - f.l. count = -21392
Immediately reclaimed -21392 bytes in heap of size 45211648 bytes(0
unmapped)
0 (atomic) + 3474584 (composite) collectable bytes in use
Finalize + initiate sweep took 0 + 0 msecs
Complete collection took 141 msecs
Initiating full world-stop collection 9 after 21712 allocd bytes
8241152 bytes in heap blacklisted for interior pointers

The collection numbers are not monotonically increasing, the heap size
suddenly jumps without indication of heap expansion, log entries are
interleaved, eventhough I think they should all be protected by the
allocation lock, and warning messages about the thread stack pointer
start appearing.  I have no idea what's going on, but it's very strange.
Did you somehow get two copies of the GC linked in?  Was there some
other opportunity for the log to get garbled?

It may be easiest to debug this by either setting a break point where
the "Thread stack pointer out of range" is generated, and seeing why the
collector sees a bad stack pointer, or by trying to understand why
GC_gc_no seems to go backwards.

Hans



-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc.log
Type: application/octet-stream
Size: 16674 bytes
Desc: gc.log
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20061115/bc43c805/gc-0001.obj


More information about the Gc mailing list