guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

deadlock in current git version on error during initialization


From: Ken Raeburn
Subject: deadlock in current git version on error during initialization
Date: Wed, 26 Aug 2009 18:51:17 -0400

After the build-order problem I just reported causes a module to fail to load, the build process hangs here:

./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc || { rm regex-posix.doc; false; } cat alist.doc [...] regex-posix.doc | GUILE_AUTO_COMPILE=0 ../meta/ uninstalled-env guile-tools snarf-check-and-output-texi > guile-procedures.texi || { rm guile-procedures.texi; false; }
ERROR: In procedure dynamic-link:
ERROR: file: "libguile-srfi-srfi-1-v-4", message: "file not found"

I poked at it a bit and it looks like two threads are waiting on mutexes:

(gdb) thr apply all bt

Thread 2 (process 49791 thread 0xf03):
#0  0x9486e2ce in semaphore_wait_signal_trap ()
#1  0x94875da5 in pthread_mutex_lock ()
#2 0x0032ae66 in scm_i_init_thread_for_guile (base=0xb0080f3c, parent=0x2d2c0) at ../../libguile/threads.c:694 #3 0x0032af33 in scm_i_with_guile_and_parent (func=0x32b870 <really_spawn>, data=0xbfff83ec, parent=0x9486e2ce) at ../../libguile/ threads.c:848 #4 0x0032b1ca in spawn_thread (d=0xb0080f3c) at ../../libguile/ threads.c:1000
#5  0x9489f155 in _pthread_start ()
#6  0x9489f012 in thread_start ()

Thread 1 (process 49791 thread 0x72f):
#0  0x9487546e in __semwait_signal ()
#1  0x948a03e6 in _pthread_cond_wait ()
#2  0x9489fdcd in pthread_cond_wait$UNIX2003 ()
#3 0x0032bc98 in scm_pthread_cond_wait (cond=0x14e, mutex=0xbfff8430) at ../../libguile/threads.c:1858 #4 0x0032bd69 in scm_spawn_thread (body=0x14e, body_data=0x14e, handler=0x14e, handler_data=0x14e) at ../../libguile/threads.c:1029 #5 0x002fec2f in start_signal_delivery_thread () at ../../libguile/ scmsigs.c:219
#6  0x9489089e in pthread_once ()
#7 0x002fec95 in scm_i_ensure_signal_delivery_thread () at ../../ libguile/scmsigs.c:231 #8 0x0032b025 in on_thread_exit (v=0x3718b0) at ../../libguile/ threads.c:632
#9  0x948a2013 in _pthread_tsd_cleanup ()
#10 0x948a1bb5 in _pthread_exit ()
#11 0x00331250 in scm_handle_by_message (handler_data=0x0, tag=<value temporarily unavailable, due to optimizations>, args=0x11310d0) at ../../libguile/throw.c:540 #12 0x0033172c in scm_ithrow (key=0x2fb20, args=0x11310d0, noreturn=1) at ../../libguile/throw.c:802 #13 0x0021ca5d in scm_error_scm (key=0x2fb20, subr=0x16aa80, message=0x16aac0, args=0x11310f0, data=0x4) at ../../libguile/error.c:93 #14 0x0021caf5 in scm_error (key=0x14e, subr=<value temporarily unavailable, due to optimizations>, message=<value temporarily unavailable, due to optimizations>, args=0x14e, rest=0x14e) at ../../ libguile/error.c:59 #15 0x0021d028 in scm_misc_error (subr=0x14e <Address 0x14e out of bounds>, message=0x14e <Address 0x14e out of bounds>, args=0x14e) at ../../libguile/error.c:282 #16 0x00350ce7 in scm_dynamic_link (filename=0x16ac90) at ../../ libguile/dynl.c:86 #17 0x0025f689 in load_extension (lib=0x16ac90, init=0x16ac30) at ../../libguile/extensions.c:105 #18 0x0025f701 in scm_load_extension (lib=0x14e, init=0x9487546e) at ../../libguile/extensions.c:152
#19 0x0024b40c in ceval (x=0x404, env=0x1131138) at eval.i.c:1346
#20 0x0025ba6a in scm_primitive_eval_x (exp=0x3df20) at ../../libguile/ eval.c:4071 #21 0x002d08bb in scm_primitive_load (filename=0x15c080) at ../../ libguile/load.c:125
#22 0x0024b40c in ceval (x=0x404, env=0x6cd630) at eval.i.c:1346
[...]
#90 0x0025a46d in ceval (x=0xd6c10, env=0x6e4458) at eval.i.c:1532
#91 0x0025b79b in scm_call_1 (proc=0xd6cd0, arg1=0x6e0018) at ../../ libguile/eval.c:3124 #92 0x0025ba4f in scm_primitive_eval_x (exp=0xd6cd0) at ../../libguile/ eval.c:4069 #93 0x002d08bb in scm_primitive_load (filename=0x3dca0) at ../../ libguile/load.c:125 #94 0x002d2241 in scm_c_primitive_load_path (filename=0x14e <Address 0x14e out of bounds>) at ../../libguile/load.c:773
#95 0x002ca64e in scm_load_startup_files () at ../../libguile/init.c:291
#96 0x0032ae9d in scm_i_init_thread_for_guile (base=0x4, parent=0x0) at ../../libguile/threads.c:700 #97 0x0032af33 in scm_i_with_guile_and_parent (func=0x2ca6d0 <invoke_main_func>, data=0xbfffe7b0, parent=0x9487546e) at ../../ libguile/threads.c:848 #98 0x0032afd9 in scm_with_guile (func=0x14e, data=0x14e) at ../../ libguile/threads.c:831 #99 0x002ca6aa in scm_boot_guile (argc=334, argv=0x14e, main_func=0x14e, closure=0x14e) at ../../libguile/init.c:360 #100 0x00001ff1 in main (argc=334, argv=0x14e) at ../../libguile/ guile.c:70

It appears that scm_i_init_thread_for_guile in thread 1 has the mutex scm_i_init_mutex locked until scm_i_init_guile returns. But many layers down, in some kind of cleanup handler, scm_spawn_thread (creating a thread in a thread-exit cleanup handler??) is waiting for some signal from the new thread that it's started up and initialized, and that thread can't initialize until it locks scm_i_init_mutex.

I get the impression that any unhandled error while loading the startup files might result in a deadlock. It should probably either cause process termination, or report some kind of error to the caller. And since we're talking about a library that can be linked into random applications, I'd prefer returning an error; after all, the application might be able to continue, or at least have its own way of reporting errors.

Ken




reply via email to

[Prev in Thread] Current Thread [Next in Thread]