Re[8]: [Gc] boehm-gc test failure on FreeBSD

Ivan Maidanski ivmai at mail.ru
Wed Aug 25 13:23:54 PDT 2010


Hi!

Wed, 25 Aug 2010 05:26:55 +0400 Dmitry Marakasov <amdmi3 at amdmi3.ru>:

> * Ivan Maidanski (ivmai at mail.ru) wrote:
> 
> > If you have difficulties while following Hans instructions, let me know.
> 
> Honestly, I understood nothing as I've never used gc.
> 
> However, I plan to learn on gc inner workings - my original plan
> was to add FreeBSD/ia64 support to boehm-gc, ...

Good.

> ... as I happened to get
> an access to Itanium2 machine and decided to fix some FreeBSD ports
> failing specifically on that architecture (it's not that wide-spread
> and there's not many people to keep ports in shape on it). I've
> started with adding regression test support to the port and ran into
> that failure.
> 
> Well, for now I'm going to read slides, faq and gc survey from the
> site. If you can give more detailed instructions on how to diagnose
> that failure meanwhile, that would be very helpful.

First, add GC_ASSERT(GC_find_header(flp)) before *flp=0 in GC_clear_fl_links and compile GC with -DGC_ASSERTIONS -DCHECKSUMS.

Also, examine fop value in GC_start_reclaim: what are the values of the chain (*fop, **fop, ***fop, etc.)?

Also, GC_write_fault_handler should be called for fop address but it seems that for some reason UNPROTECT() is not reached in it - try to test this hypothesis (and, if acknowledged, try to find that reason).

> 
> > @mail.ru
> 
> Just in case, I speak Russian :)

Not a surprise to me ;)

> 
> > > I don't think the free-list is intended to be unprotected at
> > > this stage.  GC_write_fault_handler() should just be invoked if
> > > something is still protected, and that should unprotect it.  Is
> > > GC_find_header(fault_address) zero?  Does fop in GC_start_reclaim
> > > look like it points to a free list linked through the first field
> > > of each object?  The fault address looks superficially very reasonable
> > > to me.  So the question is why GC_write_fault_handler thinks it's
> > > bad.  It might be useful to step into the handler and see what it's
> > > doing.
> 
> -- 
> Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
> amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru

> Hi, Dmitry!
> 
> If you have difficulties while following Hans instructions, let me know.
> 
> Regards.
> 
> Sat, 21 Aug 2010 01:41:09 +0000 письмо от "Boehm, Hans" <hans.boehm at hp.com>:
> 
> > I don't think the free-list is intended to be unprotected at this stage.  GC_write_fault_handler() should just be invoked if something is still protected, and that should unprotect it.  Is GC_find_header(fault_address) zero?  Does fop in GC_start_reclaim look like it points to a free list linked through the first field of each object?  The fault address looks superficially very reasonable to me.  So the question is why GC_write_fault_handler thinks it's bad.  It might be useful to step into the handler and see what it's doing.
> > 
> > Hans
> > 
> > > -----Original Message-----
> > > From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> > > On Behalf Of Ivan Maidanski
> > > Sent: Wednesday, August 18, 2010 9:52 PM
> > > To: gc at linux.hpl.hp.com
> > > Cc: Dmitry Marakasov
> > > Subject: Re[5]: [Gc] boehm-gc test failure on FreeBSD
> > > 
> > > Hello!
> > > 
> > > Hans -
> > > what's your opinion? (It seems that some page wasn't unprotected before
> > > GC_clear_fl_links.)
> > > 
> > > Regards.
> > > 
> > > >* Ivan Maidanski (ivmai at mail.ru) wrote:
> > > >
> > > >> Could you reproduce the bug with -D NO_INCREMENTAL?
> > > >
> > > >No. All tests pass with -DNO_INCREMENTAL
> > > >
> > > >Log: http://people.freebsd.org/~amdmi3/boehm-gc-noincremental.test.txt
> > > 
> > > Wed, 18 Aug 2010 23:53:22 +0400 Ivan Maidanski <ivmai at mail.ru>:
> > > 
> > > > Hello, Dmitry!
> > > >
> > > > Could you reproduce the bug with -D NO_INCREMENTAL?
> > > >
> > > > Thanks.
> > > >
> > > > Wed, 18 Aug 2010 01:53:45 +0400 Dmitry Marakasov <amdmi3 at amdmi3.ru>:
> > > >
> > > > > * Ivan Maidanski (ivmai at mail.ru) wrote:
> > > > >
> > > > > > Compile it (CVS snapshot) without -O2 but with -g and debug it
> > > (at least give us the backtrace of SEGV).
> > > > >
> > > > > It's not different from the backtrace I've given in my first
> > > letter.
> > > > >
> > > > > (gdb) run
> > > > > Starting program:
> > > /usr/home/amdmi3/projects/external/bdwgc/.libs/gctest
> > > > > Switched to incremental mode
> > > > > Emulating dirty bits with mprotect/signals
> > > > >
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x280afbe3 in GC_clear_fl_links (flp=0x80a1fb0) at reclaim.c:466
> > > > > 466	       *flp = 0;
> > > > > (gdb) bt full
> > > > > #0  0x280afbe3 in GC_clear_fl_links (flp=0x80a1fb0) at
> > > reclaim.c:466
> > > > > 	next = (void *) 0x80a1fa0
> > > > > #1  0x280afce3 in GC_start_reclaim (report_if_found=0) at
> > > reclaim.c:501
> > > > > 	fop = (void **) 0x804c674
> > > > > 	rlim = (struct hblk **) 0x80b4034
> > > > > 	lim = (void **) 0x804ca70
> > > > > 	rlp = (struct hblk **) 0x80b4034
> > > > > 	rlist = (struct hblk **) 0x80b1078
> > > > > 	should_clobber = 1
> > > > > 	kind = 1
> > > > > #2  0x280a124a in GC_finish_collection () at alloc.c:885
> > > > > 	start_time = 0
> > > > > 	finalize_time = 0
> > > > > 	done_time = 0
> > > > > #3  0x280a081d in GC_maybe_gc () at alloc.c:393
> > > > > 	n_partial_gcs = 1
> > > > > #4  0x280a0b66 in GC_collect_a_little_inner (n=1) at alloc.c:538
> > > > > 	i = 0
> > > > > #5  0x280a1d8f in GC_allocobj (gran=1, kind=1) at alloc.c:1305
> > > > > 	flh = (void **) 0x804c670
> > > > > 	tried_minor = 0
> > > > > 	retry = 0
> > > > > #6  0x280a6ddb in GC_generic_malloc_inner (lb=0, k=1) at
> > > malloc.c:126
> > > > > 	kind = (struct obj_kind *) 0x280b4094
> > > > > 	lg = 1
> > > > > 	opp = (void **) 0x804c670
> > > > > 	op = (void *) 0x0
> > > > > #7  0x280a6f51 in GC_generic_malloc (lb=0, k=1) at malloc.c:166
> > > > > 	result = (void *) 0x80ca004
> > > > > #8  0x280a7273 in GC_malloc (lb=0) at malloc.c:276
> > > > > 	op = (void *) 0x0
> > > > > 	opp = (void **) 0x804c670
> > > > > 	lg = 1
> > > > > #9  0x0804aa64 in run_one_test () at tests/test.c:1164
> > > > > 	i = 5117
> > > > > 	x = 0x80a3fd8 ""
> > > > > 	z = (char **) 0x80a1fe0
> > > > > 	y = 0x804a5c0 "U\211å¡\210ô\a\b\203À\001?\210ô\a\b]Ã\215´&"
> > > > > 	typed_time = 1
> > > > > 	start_time = 16
> > > > > 	reverse_time = 3217025448
> > > > > 	tree_time = 3217025368
> > > > > ---Type <return> to continue, or q <return> to quit---
> > > > > 	time_diff = 671405673
> > > > > #10 0x0804b1b9 in main () at tests/test.c:1412
> > > > > No locals.
> > > > >
> > > > >
> > > > > --
> > > > > Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD
> > > F9D2 F77D
> > > > > amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru
> > > http://www.amdmi3.ru
> > > > >


More information about the Gc mailing list