GNU bug report logs - #10655
[2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10655 in the body.
You can then email your comments to 10655 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guile <at> gnu.org
Subject: [2.0.3+] ‘queue_after_gc_hook’
	called during thread startup leads to SIGSEGV
Date: Mon, 30 Jan 2012 16:26:39 +0100

Hi!

I’ve just captured the following backtrace on x86_64-linux-gnu (with
v2.0.3-212-g2f3e436):

--8<---------------cut here---------------start------------->8---
Core was generated by `/home/ludo/soft/bin/guile -e (@@ (guild) main) -s /home/ludo/soft/bin/guile-too'. 
Program terminated with signal 11, Segmentation fault.
#0  queue_after_gc_hook (hook_data=<value optimized out>, fn_data=<value optimized out>,
    data=<value optimized out>) at gc.c:737
737               SCM_SETCDR (after_gc_async_cell, t->active_asyncs);
(gdb) thread apply all bt

Thread 2 (Thread 27824):
#0  0x00007f236e50b930 in sem_wait ()
   from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libpthread.so.0
#1  0x00007f236e73abe8 in GC_pthread_create (new_thread=0x7fff1406fce8, attr=0x0,
    start_routine=0x7f236ea5aa10 <spawn_thread>, arg=0x7fff1406fc60) at pthread_support.c:1582
#2  0x00007f236ea5b71c in scm_spawn_thread (body=<value optimized out>,
    body_data=<value optimized out>, handler=0x7f236ea5da90 <scm_handle_by_message>,
    handler_data=0x7f236ea9bb48) at threads.c:1125
#3  0x00007f236ea37f61 in start_signal_delivery_thread () at scmsigs.c:208
#4  0x00007f236e50ac83 in pthread_once ()
   from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libpthread.so.0
#5  0x00007f236ea3814a in scm_sigaction_for_thread (signum=<value optimized out>, handler=0x6,
    flags=0x904, thread=0x23bae40) at scmsigs.c:338
#6  0x00007f236ea39216 in scm_system_star (args=<value optimized out>) at simpos.c:133
#7  0x00007f236ea71e4b in vm_regular_engine (vm=0x2441740, program=0x24cfa20, argv=0x24458c8,
    nargs=-1) at vm-i-system.c:892
#8  0x00007f236e9eb9b3 in scm_primitive_eval (exp=0x2a98340) at eval.c:639
#9  0x00007f236ea0deab in scm_primitive_load (filename=<value optimized out>) at load.c:131
#10 0x00007f236ea0e316 in scm_primitive_load_path (args=<value optimized out>) at load.c:954
#11 0x00007f236ea71e4b in vm_regular_engine (vm=0x2441740, program=0x29bd820, argv=0x24452f0,
    nargs=-1) at vm-i-system.c:892
#12 0x00007f236ea0e4a8 in scm_primitive_load_path (args=<value optimized out>) at load.c:913
#13 0x00007f236ea71e4b in vm_regular_engine (vm=0x2441740, program=0x29afa20, argv=0x2445020,
    nargs=-1) at vm-i-system.c:892
#14 0x00007f236ea0e4a8 in scm_primitive_load_path (args=<value optimized out>) at load.c:913
#15 0x00007f236ea71e4b in vm_regular_engine (vm=0x2441740, program=0x29955e0, argv=0x2444d50,
    nargs=-1) at vm-i-system.c:892
#16 0x00007f236ea0e4a8 in scm_primitive_load_path (args=<value optimized out>) at load.c:913
#17 0x00007f236ea71e4b in vm_regular_engine (vm=0x2441740, program=0x24cfa20, argv=0x2444a80,
    nargs=-1) at vm-i-system.c:892
#18 0x00007f236e9eb9b3 in scm_primitive_eval (exp=0x260e790) at eval.c:639
#19 0x00007f236e9eba13 in scm_eval (exp=0x260e790, module_or_state=0x25f1d80) at eval.c:673
#20 0x00007f236ea390cf in scm_shell (argc=17, argv=0x7fff140712e8) at script.c:441
#21 0x00007f236ea0814d in invoke_main_func (body_data=0x7fff140711d0) at init.c:336
#22 0x00007f236e9e221a in c_body (d=0x7fff14071120) at continuations.c:512
#23 0x00007f236ea71eea in vm_regular_engine (vm=0x2441740, program=0x252ea50, argv=0x24440c0,
    nargs=-1) at vm-i-system.c:960
#24 0x00007f236e9eb683 in scm_call_4 (proc=0x252ea50, arg1=<value optimized out>,
    arg2=<value optimized out>, arg3=<value optimized out>, arg4=<value optimized out>)
    at eval.c:506
#25 0x00007f236e9e2a03 in scm_i_with_continuation_barrier (body=0x7f236e9e2210 <c_body>,
    body_data=0x7fff14071120, handler=0x7f236e9e25e0 <c_handler>, handler_data=0x7fff14071120,
    pre_unwind_handler=<value optimized out>, pre_unwind_handler_data=<value optimized out>)
    at continuations.c:450
#26 0x00007f236e9e2ab5 in scm_c_with_continuation_barrier (func=<value optimized out>,
    data=<value optimized out>) at continuations.c:546
#27 0x00007f236ea5ae2a in with_guile_and_parent (base=0x7fff14071180, data=<value optimized out>)
    at threads.c:902
#28 0x00007f236e7348d5 in GC_call_with_stack_base (fn=<value optimized out>,
    arg=<value optimized out>) at misc.c:1535
#29 0x00007f236ea5afd8 in scm_i_with_guile_and_parent (func=<value optimized out>,
    data=<value optimized out>) at threads.c:945
#30 scm_with_guile (func=<value optimized out>, data=<value optimized out>) at threads.c:951
#31 0x00007f236ea08255 in scm_boot_guile (argc=<value optimized out>, argv=<value optimized out>,
    main_func=<value optimized out>, closure=<value optimized out>) at init.c:319
#32 0x0000000000400b3a in main (argc=<value optimized out>, argv=<value optimized out>)
    at guile.c:71

Thread 1 (Thread 27825):
#0  queue_after_gc_hook (hook_data=<value optimized out>, fn_data=<value optimized out>,
    data=<value optimized out>) at gc.c:737
#1  0x00007f236ea0518c in scm_c_hook_run (hook=0x7f236ed00a10, data=0x0) at hooks.c:103
#2  0x00007f236e729951 in GC_notify_full_gc (stop_func=0x7f236e728e00 <GC_never_stop_func>)
    at alloc.c:334
#3  GC_try_to_collect_inner (stop_func=0x7f236e728e00 <GC_never_stop_func>) at alloc.c:429
#4  GC_try_to_collect_inner (stop_func=0x7f236e728e00 <GC_never_stop_func>) at alloc.c:410
#5  0x00007f236e72a65e in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0,
    retry=<value optimized out>) at alloc.c:1215
#6  0x00007f236e72a7c6 in GC_allocobj (gran=42, kind=1) at alloc.c:1302
#7  0x00007f236e72f61a in GC_generic_malloc_inner (lb=664, k=1) at malloc.c:121
#8  0x00007f236e739aff in GC_new_thread (id=139790027667200) at pthread_support.c:478
#9  0x00007f236e739fb7 in GC_register_my_thread_inner (sb=0x7f2366f12ed0,
    my_pthread=<value optimized out>) at pthread_support.c:1358
#10 0x00007f236e73a167 in GC_start_rtn_prepare_thread (pstart=0x7f2366f12eb0,
    pstart_arg=0x7f2366f12eb8, sb=0x7f2366f12ed0, arg=0x2aa1fc0) at pthread_support.c:1449
#11 0x00007f236e739993 in GC_inner_start_routine (sb=<value optimized out>,
    arg=<value optimized out>) at pthread_start.c:50
#12 0x00007f236e7348d5 in GC_call_with_stack_base (fn=<value optimized out>,
    arg=<value optimized out>) at misc.c:1535
#13 0x00007f236e504cec in start_thread ()
   from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libpthread.so.0
#14 0x00007f236d0111ed in clone ()
   from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libc.so.6
--8<---------------cut here---------------end--------------->8---

The problems seems to be that the after-gc-hook runs while the thread is
being created and not yet a full-blown Guile thread.

Thanks,
Ludo’.

Message #8 received at 10655 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10655 <at> debbugs.gnu.org
Subject: Re: bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV
Date: Mon, 30 Jan 2012 16:33:42 +0100

On Mon 30 Jan 2012 16:26, ludo <at> gnu.org (Ludovic Courtès) writes:

> #0  queue_after_gc_hook (hook_data=<value optimized out>, fn_data=<value optimized out>,
>     data=<value optimized out>) at gc.c:737
> #1  0x00007f236ea0518c in scm_c_hook_run (hook=0x7f236ed00a10, data=0x0) at hooks.c:103
> #2  0x00007f236e729951 in GC_notify_full_gc (stop_func=0x7f236e728e00 <GC_never_stop_func>)
>     at alloc.c:334
> #3  GC_try_to_collect_inner (stop_func=0x7f236e728e00 <GC_never_stop_func>) at alloc.c:429
> #4  GC_try_to_collect_inner (stop_func=0x7f236e728e00 <GC_never_stop_func>) at alloc.c:410
> #5  0x00007f236e72a65e in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0,
>     retry=<value optimized out>) at alloc.c:1215
> #6  0x00007f236e72a7c6 in GC_allocobj (gran=42, kind=1) at alloc.c:1302
> #7  0x00007f236e72f61a in GC_generic_malloc_inner (lb=664, k=1) at malloc.c:121
> #8  0x00007f236e739aff in GC_new_thread (id=139790027667200) at pthread_support.c:478
> #9  0x00007f236e739fb7 in GC_register_my_thread_inner (sb=0x7f2366f12ed0,
>     my_pthread=<value optimized out>) at pthread_support.c:1358
> #10 0x00007f236e73a167 in GC_start_rtn_prepare_thread (pstart=0x7f2366f12eb0,
>     pstart_arg=0x7f2366f12eb8, sb=0x7f2366f12ed0, arg=0x2aa1fc0) at pthread_support.c:1449
> #11 0x00007f236e739993 in GC_inner_start_routine (sb=<value optimized out>,
>     arg=<value optimized out>) at pthread_start.c:50
> #12 0x00007f236e7348d5 in GC_call_with_stack_base (fn=<value optimized out>,
>     arg=<value optimized out>) at misc.c:1535
> #13 0x00007f236e504cec in start_thread ()
>    from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libpthread.so.0
> #14 0x00007f236d0111ed in clone ()
>    from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libc.so.6
>
> The problems seems to be that the after-gc-hook runs while the thread is
> being created and not yet a full-blown Guile thread.

Interesting.  I'll see what I can do.

A
-- 
http://wingolog.org/

Message #11 received at 10655 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10655 <at> debbugs.gnu.org
Subject: Re: bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV
Date: Mon, 30 Jan 2012 16:41:17 +0100

[Message part 1 (text/plain, inline)]

Hi!

I’m testing this patch:

[Message part 2 (text/x-patch, inline)]

diff --git a/libguile/gc.c b/libguile/gc.c
index 7816801..97dfcd8 100644
--- a/libguile/gc.c
+++ b/libguile/gc.c
@@ -730,14 +730,17 @@ queue_after_gc_hook (void * hook_data SCM_UNUSED,
   if (scm_debug_cells_gc_interval == 0)
 #endif
     {
-      scm_i_thread *t = SCM_I_CURRENT_THREAD;
-
-      if (scm_is_false (SCM_CDR (after_gc_async_cell)))
-        {
-          SCM_SETCDR (after_gc_async_cell, t->active_asyncs);
-          t->active_asyncs = after_gc_async_cell;
-          t->pending_asyncs = 1;
-        }
+      if (SCM_I_CURRENT_THREAD != NULL && SCM_I_CURRENT_THREAD->guile_mode)
+	{
+	  scm_i_thread *t = SCM_I_CURRENT_THREAD;
+
+	  if (scm_is_false (SCM_CDR (after_gc_async_cell)))
+	    {
+	      SCM_SETCDR (after_gc_async_cell, t->active_asyncs);
+	      t->active_asyncs = after_gc_async_cell;
+	      t->pending_asyncs = 1;
+	    }
+	}
     }
 
   return NULL;

[Message part 3 (text/plain, inline)]

Rationale:

  - With TLS, SCM_I_CURRENT_THREAD is never NULL but the whole struct,
    including ‘guile_mode’, is zero when the thread starts.

  - Without TLS, SCM_I_CURRENT_THREAD is NULL until ‘guilify_self_1’ has
    been called.

Thoughts?

(My “benchmark” has been running for some time already and the bug
hasn’t shown up again.)

Thanks,
Ludo’.

Message #16 received at 10655-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10655-done <at> debbugs.gnu.org
Subject: Re: bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV
Date: Mon, 30 Jan 2012 20:42:42 +0100

This was eventually fixed by commit
e1fbe716e8596b7027af57623ebc72a0c6393187 (“fix hook invocation during
thread guilification”).

Thanks!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.