[Gc] Re: [PATCH] Dealing with `.data.rel.ro'

Boehm, Hans hans.boehm at hp.com
Sun May 24 16:47:06 PDT 2009


Thanks.

Unfortunately, I haven't been immediately able to reproduce this on a RedHat 5.1 machine with gcc 4.1.2.  Can others reproduce this?

I assume that 0x7f9ba26eb9b8 (top -> mse_start) is a completely bogus address?
mse->descr appears to describe the length of an object (lsbs zero), but is way too big.  It looks like somehow a completely bogus entry worked itself onto the mark stack.  It would be good to check load_segs and n_load_segs in dyn_load.c and see whether that contains any bogus entries.  Each entry should describe either one or two valid address ranges.  (In the case of one, the second one should be all zeroes.   Other empty ranges can occur and are OK.)

If those look OK, could you try explicitly undefining PT_GNU_RELRO before it is first tested?  I think that should essentially get rid of all the newly added code there.  It would be good to confirm that this patch is actually the cause of the problem.

If the problem is deterministic, another good plan of attack might be to remember the value of top at the failure point, and then rerun with a watchpoint there.

The smashtest output looks OK.  It's really a test that memory overwrite errors get reported without crashing in the process.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Petter Urkedal
> Sent: Saturday, May 23, 2009 5:12 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Re: [PATCH] Dealing with `.data.rel.ro'
> 
> On 2009-05-23, Petter Urkedal wrote:
> > This revision causes segfault for hugetest and 
> threadleaktest test on 
> > Linux x86_64:
> 
> After I --enable-gc-assertions I get:
> 
> Assertion failure: /home/urkedal/proj/bdwgc-pu/mark.c:905
> Assertion failure: /home/urkedal/proj/bdwgc-pu/mark.c:905
> assertion failure
> /bin/sh: line 4:  9102 Aborted                 (core dumped) 
> ${dir}$tst
> FAIL: hugetest
> Assertion failure: /home/urkedal/proj/bdwgc-pu/mark.c:905
> assertion failure
> Assertion failure: /home/urkedal/proj/bdwgc-pu/mark.c:905
> assertion failure
> /bin/sh: line 4:  9130 Aborted                 (core dumped) 
> ${dir}$tst
> FAIL: threadleaktest
> 
> Some info from the debugger (ask if you need more):
> 
> (gdb) p/x *top
> $2 = {mse_start = 0x7f9ba26eb9b8, mse_descr = 0x1c57f24969288058}
> (gdb) p/x GC_greatest_plausible_heap_addr
> $3 = 0x2643a0a
> (gdb) p/x GC_least_plausible_heap_addr
> $4 = 0x631ff8
> 
> I also noted that smashtest complains about smashed heap objects:
> 
> GC_check_heap_block: found smashed heap objects:
> 0x63ffe8 in or near object at 
> 0x63ffc0(/home/urkedal/proj/bdwgc-pu/tests/smash_test.c:21, sz=40)
> GC_check_heap_block: found smashed heap objects:
> 0x63ffe8 in or near object at 
> 0x63ffc0(/home/urkedal/proj/bdwgc-pu/tests/smash_test.c:21, sz=40)
> GC_check_heap_block: found smashed heap objects:
> 0x6e3f98 in or near object at 
> 0x6e3f70(/home/urkedal/proj/bdwgc-pu/tests/smash_test.c:21, sz=40)
> 0x63ffe8 in or near object at 
> 0x63ffc0(/home/urkedal/proj/bdwgc-pu/tests/smash_test.c:21, sz=40)
> PASS: smashtest
> 
> Shouldn't smashtest return a non-zero exit status in this case?
> 
> Petter
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list