Re[2]: [Gc] Problem with GC on FreeBSD

Ivan Maidanski ivmai at mail.ru
Sat Apr 28 05:07:29 PDT 2012


Hi Petter,

Sorry for the delay.

To my current understanding, the problem caused by missing GC_register_displacement(sizeof(oh)) (i.e. light "debugging_started") in GC_store_debug_info_inner. What do you think? (I guess I'll have some time to check your test case with such a fix tomorrow).

Regards.

Tue, 24 Apr 2012 08:37:56 +0200 Petter Urkedal <urkedal at nbi.dk>:
> Hi Ivan,
> 
> On closer inspection this looks like the bug I wrote about in
> "Segfault for certain sizes of GC_Thread_Rep" (2011-09-15 00:03).
> It can be reproduced with the attached diff and test case using
> --enable-gc-debug and for new versions, --disable-disclaim.  The
> conditions that must be met to trigger the bug is
> 
> * GC_Thread_Rep is at least 560 bytes.
> * The GC_INTERNAL_MALLOC expands to GC_debug_generic_malloc_inner.
> * GC_all_interior_pointers is 0.
> 
> GC_debug_generic_malloc_inner stores its metadata at the beginning of
> the objects.  That's what caused the problem for GC_finalized_malloc
> before we moved the header to the end and added the
> GC_set_all_interior_pointers(0) to the test case.
> 
> Is debug allocation supposed to work with GC_all_interior_pointers = 0?
> 
> Petter
> 
> On 2012-04-23, Ivan Maidanski wrote:
> > Hi Petter,
> > 
> > I confirm a problem with disclaim_test in 'fix-freelist-check-and-specific'
> on Linux/x86:
> > 
> > CFLAGS=-DUSE_CUSTOM_SPECIFIC ./configure --enable-gc-debug
> > 
> > Threaded disclaim test.
> > Segmentation fault.
> > 
> > I haven't time to run in under gdb or test other scenarios today.
> > 
> > Regards.
> > 
> > Sun, 22 Apr 2012 22:08:31 +0300 Vitaly Magerya <vmagerya at gmail.com>:
> > > Ivan Maidanski <ivmai at mail.ru> wrote:
> > > > Hi Petter, Vitaly and Hans,
> > > >
> > > > Vitaly -
> > > > 1. Please test branch 'fix-freelist-check-and-specific' (it should only
> fix
> > > > the problem for --enable-gc-assertions)
> > > 
> > > Here's the summary of tests I made against fix-freelist-check-and-specific
> > > branch (hopefully I didn't make any stupid mistakes during testing,
> > > as there are many configurations; feel free to ask for a re-test):
> > > 
> > > With USE_CUSTOM_SPECIFIC, without gc-debug, without gc-assertions:
> > >     all tests pass, stklos hangs on thread tests
> > > 
> > > With USE_CUSTOM_SPECIFIC, without gc-debug, with gc-assertions:
> > >     all tests pass, stklos hangs on thread tests
> > > 
> > > With USE_CUSTOM_SPECIFIC, with gc-debug, without gc-assertions:
> > >     disclaim_test segfaults (it passes on a very rare occasion)
> > > 
> > > Backtrace:
> > > 
> > > #0  0x000000080086c1f1 in GC_finalized_malloc (client_lb=24,
> > > fclos=0x401690) at fnlz_mlc.c:145
> > > #1  0x0000000000400ecf in pair_new (car=0xba9ac0, cdr=0x0) at
> > > tests/disclaim_test.c:114
> > > #2  0x000000000040125c in test (data=0x0) at tests/disclaim_test.c:178
> > > #3  0x0000000800869f37 in GC_inner_start_routine (sb=0x7fffff9fcf90,
> > > arg=0x845f90) at pthread_start.c:56
> > > [...]
> > > 
> > > With USE_CUSTOM_SPECIFIC, with gc-debug, with gc-assertions:
> > >     disclaim_test segfaults (sometimes)
> > > 
> > > With USE_PTHREAD_SPECIFIC, without gc-debug, without gc-assertions:
> > >     all tests pass, stklos segfaults
> > > 
> > > With USE_PTHREAD_SPECIFIC, without gc-debug, with assertions:
> > >     all tests pass, stklos fails before threading tests:
> > >     "Assertion failure: thread_local_alloc.c:176".
> > > 
> > > Here's the backtrace:
> > > 
> > > #0  0x0000000801866a7c in thr_kill () from /lib/libc.so.7
> > > #1  0x0000000801903d3b in abort () from /lib/libc.so.7
> > > #2  0x000000080119a97f in GC_malloc (bytes=56) at thread_local_alloc.c:175
> > > [... STklos stuff ...]
> > > 
> > > With USE_PTHREAD_SPECIFIC, with gc-debug, without gc-assertions:
> > >     disclaim_test sometimes segfaults (rarely)
> > > 
> > > Backtrace:
> > > 
> > > #0  0x00000008008635fd in GC_size (p=0x0) at misc.c:452
> > > #1  0x0000000800858c87 in GC_debug_free_inner (p=0x916ac0) at
> dbg_mlc.c:849
> > > #2  0x0000000800869ea6 in GC_delete_gc_thread (t=0x916ac0) at
> > > pthread_support.c:571
> > > #3  0x000000080086a9dd in GC_pthread_join (thread=0x801008400,
> > > retval=0x0) at pthread_support.c:1370
> > > #4  0x00000000004013b6 in main () at tests/disclaim_test.c:212
> > > 
> > > (Sometimes the values of p and t at #1 and #2 differ).
> > > 
> > > With USE_PTHREAD_SPECIFIC, with gc-debug, with gc-assertions:
> > >     disclaim_test sometimes fails: "Assertion failure: dbg_mlc.c:843"
> > > 
> > > Here's the backtrace:
> > > 
> > > #0  0x0000000800d17a7c in thr_kill () from /lib/libc.so.7
> > > #1  0x0000000800db4d3b in abort () from /lib/libc.so.7
> > > #2  0x0000000800859a6f in GC_debug_free_inner (p=0x91aac0) at
> dbg_mlc.c:843
> > > #3  0x000000080086ecc0 in GC_delete_gc_thread (t=0x91aac0) at
> > > pthread_support.c:571
> > > #4  0x000000080086ffc0 in GC_pthread_join (thread=0x801408400,
> > > retval=0x0) at pthread_support.c:1370
> > > #5  0x00000000004013b6 in main () at tests/disclaim_test.c:212
> > > 
> > > The error happens because GC_base(p) at dbg_mlc.c:842 returns 0. It does
> > > so because of HBLK_IS_FREE(candidate_hdr) == 0 condition at misc.c:417.
> > > 
> > > > 2. I'm still puzzled what's the problem USE_CUSTOM_SPECIFIC (which is
> > > > defined by default for FreeBSD for now unless you set
> USE_PTHREAD_SPECIFIC)
> > > > - looks like some thread is not unregistered (i.e. GC_remove_specific
> not
> > > > called) on exit.
> > > 
> > > GC_remove_specific is indeed never called prior to the segfault (in
> > > configuration where USE_CUSTOM_SPECIFIC and --enable-gc-debug are
> > > used). It is called without --enable-gc-debug, it is called on those
> > > rare occasions when disclaim_test passes, but not when it segfaults.
> > > _______________________________________________
> > > Gc mailing list
> > > Gc at linux.hpl.hp.com
> > > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> > > 
> > 
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
> _______________________________________________
> 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