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

Ivan Maidanski ivmai at mail.ru
Sun Apr 29 07:36:17 PDT 2012


Hi Vitaly,

Based on your report:
1. There's a bug associated with enable-gc-debug - Petter already discovered the cause and te proper fix will be applied soon
2. If gc-debug is off then only stklos (not included into bdwgc) hangs regardless of USE_xxx_SPECIFIC, right?

I'll try to check stklos problem tomorrow.

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/
> 



More information about the Gc mailing list