[Gc] Re: Re: Re: FW: Re: Cannot print call chain
hans.boehm at hp.com
Thu Jul 15 11:35:05 PDT 2010
> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of biosli
> Sent: Thursday, July 15, 2010 3:52 AM
> To: gc at linux.hpl.hp.com
> Subject: [Gc] Re: Re: Re: FW: Re: Cannot print call chain
> Hi all:
> Boehm, Hans <hans.boehm at ...> writes:
> > It would also be good to verify that p and GC_base(p) are the same.
> > This test checks that the allocated object is big enough to hold the
> information. The fact that it
> > doesn't appear to be suggests that either there's something seriously
> inconsistent here, or something
> > has gone seriously wrong when the object was allocated.
> > Hans
> To Hans:
> At GC_has_other_debug_info I compare p and the pointer GC_base(p)
> return, they
> are same.
> And I add PRINT_CALL_CHAIN in GC_debug_malloc after ADD_CALL_CHAIN, the
> chain can print out.
If you can catch the allocation of that specific object, can you check *GC_find_header(p) at both the allocation point, and when the object is printed? Does the perceived size of the object change? Only the mark bits should change in the header.
> > > > Ivan Maidanski <ivmai at ...> writes:
> > > > > > GC_debug_print_heap_obj_proc calls GC_HAS_DEBUG_INFO(p), and
> > > return false
> > > > > > because (sz < DEBUG_BYTES + EXTRA_BYTES).
> > >
> > > And what are that values (sz, DEBUG_BYTES, EXTRA_BYTES) when (sz <
> > > DEBUG_BYTES + EXTRA_BYTES)?
> To Ivan:
> sz is 40.
> BTW, before I get memory leak info, i got two smash info before.
> GC_check_heap_block: found smashed heap objects:
> 01F21C60 in or near object at 01F21C68(<smashed>, appr. sz = 5)
> 01F21C98 in or near object at 01F21CA0(<smashed>, appr. sz = 5)
> When I use old version of GC, smashs were never happen.
> Are the smashs make the call chain problem?
That certainly doesn't sound good. I'm also a bit surprised by the appr. sz information here. Allocated objects should have size that's a multiple of GC_GRANULE_BYTES. The value here is calculated in a slightly odd way here, but I would still like to understand if this is correct. Both (a) looking at *GC_find_header(<smashed addr>) and (b) dumping the bytes around the smashed address may tell us more about what's going on there.
> Thanks all your help!!
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc