[Gc] Problem with GC on FreeBSD

Petter Urkedal urkedal at nbi.dk
Mon Apr 23 23:37:56 PDT 2012


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/
-------------- next part --------------
diff --git a/include/private/pthread_support.h b/include/private/pthread_support.h
index 8820fc4..25a4ae1 100644
--- a/include/private/pthread_support.h
+++ b/include/private/pthread_support.h
@@ -112,6 +112,7 @@ typedef struct GC_Thread_Rep {
 #   ifdef THREAD_LOCAL_ALLOC
         struct thread_local_freelists tlfs;
 #   endif
+    long XXX[20];
 } * GC_thread;
 
 # define THREAD_TABLE_SZ 256    /* Must be power of 2   */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bisect_test.c
Type: text/x-c
Size: 3968 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20120424/97dca670/bisect_test.bin


More information about the Gc mailing list