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

Ivan Maidanski ivmai at mail.ru
Sat Sep 11 03:57:21 PDT 2010


Hello!

I've fixed this (FreeBSD) issue.

1. It turned out that on FreeBSD v7+, si_code on SIGSEGV is 2 (which doesn't correspond to BUS_PAGE_FAULT or any other mnemonic (like in OSF1 case)).

2. I've also fixed CODE_OK expresssion for HPUX :
  was: SIG_OK && (si -> si_code == SEGV_ACCERR) || ... || (si -> si_code == BUS_OBJERR)
  now: SIG_OK && (si -> si_code == SEGV_ACCERR || ... || si -> si_code == BUS_OBJERR)
 it's now more strict but should also be more correct.

3. Also, I've adjusted some DATASTART definitions for FreeBSD to make them look uniform.
  was: GC_FreeBSDGetDataStart(0x1000, &etext)
  now: GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)
  where etext is defined as extern char etext[].
  This should be a stylistic change (which also prevents a compiler warning) according to the C language spec.

Regards.

Fri, 03 Sep 2010 21:50:01 +0400 Ivan Maidanski <ivmai at mail.ru>:

> Hello, Dmitry!
> How are you doing?
> I could also try to catch the bug if tell me what precise environment you are
> using.
> Regards.
> Thu, 26 Aug 2010 00:23:54 +0400 Ivan Maidanski <ivmai at mail.ru>:
> > 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
> > > > > > >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 6811 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20100911/162f7622/attachment-0001.obj


More information about the Gc mailing list