bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV

bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV

[Ludovic Courtès]

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’.

bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV

[Andy Wingo]

On Mon 30 Jan 2012 16:26, ludo@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/

bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 36 bytes --]

Hi!

I’m testing this patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 882 bytes --]

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;

[-- Attachment #3: Type: text/plain, Size: 386 bytes --]


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’.

bug#10655: [2.0.3+] ‘queue_after_gc_hook’ called during thread startup leads to SIGSEGV

[Ludovic Courtès]

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

Thanks!

Ludo’.