From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.lisp.guile.user Subject: Re: guile 2.0.9 build on mingw Date: Wed, 12 Jun 2013 20:46:07 +0300 Message-ID: <83a9mvkysg.fsf@gnu.org> References: <83sj1hv2ml.fsf@gnu.org> <874ndx9y7h.fsf@pobox.com> <83ip2bt4qk.fsf@gnu.org> <8761xqhyyt.fsf@gnu.org> <83li6mt18y.fsf@gnu.org> <83wqq3mcq9.fsf@gnu.org> <87k3m3kor5.fsf@gnu.org> <83ehcalysu.fsf@gnu.org> <87sj0pvl4a.fsf@tines.lan> <837gi1n3v5.fsf@gnu.org> <87k3m1vg8b.fsf@tines.lan> <83txl4lhby.fsf@gnu.org> <87txl4mh5p.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1371059177 24246 80.91.229.3 (12 Jun 2013 17:46:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Jun 2013 17:46:17 +0000 (UTC) Cc: guile-user@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jun 12 19:46:16 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ump7g-0000ol-AQ for guile-user@m.gmane.org; Wed, 12 Jun 2013 19:46:16 +0200 Original-Received: from localhost ([::1]:58489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ump7g-0005Yp-0B for guile-user@m.gmane.org; Wed, 12 Jun 2013 13:46:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ump7U-0005Yh-J0 for guile-user@gnu.org; Wed, 12 Jun 2013 13:46:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ump7S-0000OE-R5 for guile-user@gnu.org; Wed, 12 Jun 2013 13:46:04 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:33325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ump7S-0000Nu-DE; Wed, 12 Jun 2013 13:46:02 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MOA00600JWJ6V00@a-mtaout20.012.net.il>; Wed, 12 Jun 2013 20:46:00 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MOA005LXK0NUE80@a-mtaout20.012.net.il>; Wed, 12 Jun 2013 20:46:00 +0300 (IDT) In-reply-to: <87txl4mh5p.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10428 Archived-At: > From: ludo@gnu.org (Ludovic Court=C3=A8s) > Cc: Mark H Weaver , guile-user@gnu.org > Date: Wed, 12 Jun 2013 00:11:46 +0200 >=20 > > What eventually did the trick was configuring --with-threads=3Dno= . Once > > I did that, the build ran successfully and almost 100% cleanly to > > completion. (I will report the details about "almost" later.) > > > > I will try to compare the two builds and find what breaks the one= with > > threads. Since my knowledge about pthreads in general and on Win= dows > > in particular is strictly zero, I'm not sure I'll know where to l= ook. > > So perhaps the following observation will help someone here to co= me up > > with ideas or hints about where to look: Guile gets stuck when it= is > > about to exit. That is, it processes its input completely (e.g., > > compiles the .scm file), writes out the corresponding output (e.g= ., > > the .go file), announces that the output was written, and then ge= ts > > stuck. So this suggests something related to some bookkeeping do= ne at > > exit; any ideas what that could be? >=20 > The backtrace you reported before suggests that it=E2=80=99s stuck = waiting for a > signal delivery thread mutex, right? I have no idea how this would > happen, though. I looked deeper into this. What I saw surprised me, but maybe that's because I know nothing about pthreads, nor how Guile uses them. I will describe my findings in the hope that someone here will know more. In a nutshell, I think the hang waiting for a mutex is a symptom, not the problem; see below. What I did was stop Guile at the entry to 'main', and then attach GDB and set a breakpoint at scm_i_ensure_signal_delivery_thread, before letting Guile proceed. I expected that function to be called some time during the startup, and I expected to see GDB announce a new thread. Surprisingly, none of that happened. Instead, the function is called when Guile is done (it was compiling a .scm file), and is exiting! See the backtrace below; you can clearly see that the top-level call-stack frame is in ExitProcess, and the whole sequence of calls leading to the attempt to create a signal delivery thread starts in on_thread_exit. What happens next is that the attempt to launch that thread fails here: SCM scm_spawn_thread (scm_t_catch_body body, void *body_data, =09=09 scm_t_catch_handler handler, void *handler_data) { spawn_data data; scm_i_pthread_t id; int err; data.parent =3D scm_current_dynamic_state (); data.body =3D body; data.body_data =3D body_data; data.handler =3D handler; data.handler_data =3D handler_data; data.thread =3D SCM_BOOL_F; scm_i_pthread_mutex_init (&data.mutex, NULL); scm_i_pthread_cond_init (&data.cond, NULL); scm_i_scm_pthread_mutex_lock (&data.mutex); err =3D scm_i_pthread_create (&id, NULL, spawn_thread, &data);= <<<<<<< if (err) =09 { =09 scm_i_pthread_mutex_unlock (&data.mutex); =09 errno =3D err; =09 scm_syserror (NULL); =09 } scm_i_pthread_create returns err =3D 11 (EAGAIN), and then Guile call= s scm_syserror. I believe that call outputs the Scheme backtrace, and then Guile hangs as I described. The call to start the signal delivery thread comes from here: /* Perform thread tear-down, in guile mode. */ static void * do_thread_exit (void *v) { scm_i_thread *t =3D (scm_i_thread *) v; /* Ensure the signal handling thread has been launched, becaus= e we might be =09 shutting it down. This needs to be done in Guile mode. */ scm_i_ensure_signal_delivery_thread (); <<<<<<<<<<<<<<<<<<<<< Why isn't the signal delivery thread launched at program start, and why is it launched at exit? Also, is it possible for you or someone else to describe how the signal delivery stuff is supposed to work, especially since there are some MinGW related comments in scmsigs.c that mention signals between processes (how's that related? Guile is a single process, right?)? I'd like to understand a bit more what is going on here. > > Another set of disabled features is the network related functions= -- > > for some reason, the build process insists on h_errno being avail= able, > > although h_errno is an obsolete facility that AFAIK no one is tre= ating > > seriously anymore. Why not use errno instead? >=20 > I don=E2=80=99t know. It=E2=80=99s used only in net_db.c, and only= if =E2=80=98h_errno=E2=80=99 is > available. >=20 > Is there any harm in using it when it=E2=80=99s available? No, of course not. The harm is to disable all network features when h_errno is _not_ available. > Could it be that older-but-not-too-old MinGW versions required use = of > =E2=80=98h_errno=E2=80=99? I sincerely doubt that. Windows doesn't have h_errno, and AFAIK neve= r had. Here's the backtrace when scm_spawn_thread is called during exit: Breakpoint 1, scm_spawn_thread ( =09 body=3Dbody@entry=3D0x436350 , =09 body_data=3Dbody_data@entry=3D0x0, handler=3D0x4317a4 , =09 handler_data=3Dhandler_data@entry=3D0x4e5a60 ) at threads.c:1119 1119 { (gdb) bt #0 scm_spawn_thread (body=3Dbody@entry=3D0x436350 , =09 body_data=3Dbody_data@entry=3D0x0, handler=3D0x4317a4 , =09 handler_data=3Dhandler_data@entry=3D0x4e5a60 ) at threads.c:1119 #1 0x00436328 in start_signal_delivery_thread () at scmsigs.c:2= 00 #2 0x6248b751 in pthread_once () from d:\usr\bin\pthreadGC2.dll #3 0x0043642c in scm_i_ensure_signal_delivery_thread () at scms= igs.c:212 #4 0x00432c10 in do_thread_exit (v=3D0x9b0f00) at threads.c:671 #5 0x0045f8bc in c_body (d=3D0x28f6a0) at continuations.c:511 #6 0x00454b9b in vm_regular_engine (vm=3D0xb95c80, program=3D0x= 0, =09 argv=3D0x23f00a4, nargs=3D5121210) at vm-i-system.c:855 #7 0x00414608 in scm_call_4 (proc=3D0x926b28, arg1=3Darg1@entry= =3D0x404, =09 arg2=3Darg2@entry=3D0x5408d80, arg3=3Darg3@entry=3D0x5408d70, =09 arg4=3Darg4@entry=3D0x5408d60) at eval.c:507 #8 0x004312b2 in scm_catch_with_pre_unwind_handler (key=3D0x404= , =09 thunk=3D0x5408d80, handler=3D0x5408d70, pre_unwind_handler=3D0x54= 08d60) =09 at throw.c:86 #9 0x0043144e in scm_c_catch (tag=3Dtag@entry=3D0x404, body= =3D0x5408d80, =09 body@entry=3D0x45f8ac , body_data=3D0x5408d70, =09 body_data@entry=3D0x28f6a0, handler=3D0x5408d60, =09 handler@entry=3D0x45fb60 , =09 handler_data=3Dhandler_data@entry=3D0x28f6a0, =09 pre_unwind_handler=3Dpre_unwind_handler@entry=3D0x45f9cc , pre_unwind_handler_data=3Dpre_unwind_handler_data@entry= =3D0xb95c40) at throw.c:213 #10 0x0045ff4b in scm_i_with_continuation_barrier ( =09 body=3Dbody@entry=3D0x45f8ac , body_data=3Dbody_data@entr= y=3D0x28f6a0, =09 handler=3Dhandler@entry=3D0x45fb60 , =09 handler_data=3Dhandler_data@entry=3D0x28f6a0, =09 pre_unwind_handler=3Dpre_unwind_handler@entry=3D0x45f9cc , pre_unwind_handler_data=3D0xb95c40) at continuations.c:= 449 #11 0x0045ffdc in scm_c_with_continuation_barrier ( =09 func=3D0x432c00 , data=3D0x9b0f00) at continuatio= ns.c:545 #12 0x00431e04 in with_guile_trampoline (data=3D0x28f790) at thr= eads.c:890 #13 0x709cffa0 in ?? () from d:\usr\bin\libgc-1.dll #14 0x004326ec in with_gc_active (data=3D0x28f790, =09 func=3D0x431dec ) at threads.c:238 #15 with_guile_and_parent (base=3D0x28f768, data=3D0x28f790) at = threads.c:936 #16 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll #17 0x004328f0 in scm_i_with_guile_and_parent (parent=3D, =09 data=3D0x9b0f00, func=3D0x432c00 ) at threads.c:9= 51 #18 scm_with_guile (func=3D0x432c00 , data=3D0x9= b0f00) =09 at threads.c:957 #19 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll #20 0x00431e76 in on_thread_exit (v=3D0x9b0f00) at threads.c:754 #21 0x62481f14 in ptw32_callUserDestroyRoutines () =09from d:\usr\bin\pthreadGC2.dll #22 0x624855a1 in pthread_win32_thread_detach_np () =09from d:\usr\bin\pthreadGC2.dll #23 0x62485a45 in DllMain@12 () from d:\usr\bin\pthreadGC2.dll #24 0x624810ed in DllMainCRTStartup@12 () from d:\usr\bin\pthrea= dGC2.dll #25 0x77c69950 in ntdll!RtlQueryEnvironmentVariable () =09from C:\Windows\SysWOW64\ntdll.dll #26 0x62480000 in ?? () #27 0x77c7d6b2 in ntdll!LdrShutdownProcess () =09from C:\Windows\SysWOW64\ntdll.dll #28 0x624810c0 in __dll_exit () from d:\usr\bin\pthreadGC2.dll #29 0x77c7d554 in ntdll!RtlExitUserProcess () =09from C:\Windows\SysWOW64\ntdll.dll #30 0x75e97a0d in KERNEL32!ExitProcess () =09from C:\Windows\syswow64\kernel32.dll