unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* deadlock in current git version on error during initialization
@ 2009-08-26 22:51 Ken Raeburn
  2009-08-27 21:19 ` Andy Wingo
  0 siblings, 1 reply; 2+ messages in thread
From: Ken Raeburn @ 2009-08-26 22:51 UTC (permalink / raw)
  To: guile-devel

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




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-08-27 21:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-26 22:51 deadlock in current git version on error during initialization Ken Raeburn
2009-08-27 21:19 ` Andy Wingo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).