Re: guile 2.0.9 build on mingw

[Eli Zaretskii <eliz@gnu.org>]

Ping!  Any ideas on the below?

> Date: Wed, 22 May 2013 18:26:59 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: guile-user@gnu.org
> 
> > From: Andy Wingo <wingo@pobox.com>
> > Cc: Panicz Maciej Godek <godek.maciek@gmail.com>,  guile-user@gnu.org
> > Date: Mon, 20 May 2013 22:46:10 +0200
> > 
> > >>   GEN      guile-procedures.texi
> > >> 
> > >> but when I ask make to keep going, the same error appears when guilec tries
> > >> to compile ice-9/eval.go.
> > >
> > > I reported a similar problem here:
> > >
> > >   http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html
> > >
> > > So far no replies.  I hope to hear from them some day.
> > 
> > Thanks for the ping :)  Can you run meta/gdb-uninstalled-guile and get a
> > backtrace somehow?
> 
> I did my best, see below.  Running meta/gdb-uninstalled-guile cannot
> help here, because the problem happens in a child Guile process, and
> GDB on Windows doesn't support follow-fork/exec-mode.
> 
> Instead, I concatenated manually all the *.doc files, then ran this
> command (the one that crashed, as revealed by "make V=1"):
> 
>   GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0  ../meta/uninstalled-env \
>     guild snarf-check-and-output-texi < all-docs.doc > guile-procedures.texi
> 
> and then attached GDB to the child Guile process and looked around.
> 
> What I found is something I'll need a lot of help with.  The backtrace
> displayed by Guile looks like this:
> 
>      Backtrace:
>      In unknown file:
> 	?: 4 [apply-smob/1 #<catch-closure c1ddf0> quit #<unspecified>]
>      In ice-9/eval.scm:
>       484: 3 [eval # #]
>       481: 2 [lp (#<fluid 13>) (#<procedure 41c1c78 at ice-9/eval.scm:264:7 %args>)]
>      In unknown file:
> 	?: 1 [apply-smob/1 #<catch-closure 643d730>]
>      In ice-9/eval.scm:
>       481: 0 [lp (#<fluid 12>) ((#<catch-closure 643d710>))]
> 
>      ice-9/eval.scm:481:19:
>                            ^
> 
> Yes, the last line is really unfinished, and the cursor sits where
> shown.  But typing at this stage has no effect.
> 
> Setting a breakpoint on all 3 places that print "Backtrace:", I get
> this C backtrace:
> 
>   Breakpoint 2, print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
>       port=0x935c40) at continuations.c:490
>   490           scm_display_backtrace_with_highlights (stack, port,
>   (gdb) bt
>   #0  print_exception_and_backtrace (args=0x37ff610, tag=0x89c6f0,
>       port=0x935c40) at continuations.c:490
>   #1  pre_unwind_handler (error_port=error_port@entry=0x935c40, tag=0x89c6f0,
>       args=args@entry=0x37ff610) at continuations.c:534
>   #2  0x00430eae in apply_catch_closure (clo=0x643d710, args=0x37ff608)
>       at throw.c:151
>   #3  0x00454b8b in vm_regular_engine (vm=0x935c80, program=0x8f5d90,
>       argv=0xa01120, nargs=5121210) at vm-i-system.c:855
>   #4  0x0045668b in scm_call_with_vm (vm=0x935c80, proc=0x896af0,
>       args=<optimized out>) at vm.c:1045
>   #5  0x00412f87 in scm_apply (proc=0x935c80, arg1=0x896af0,
>       args=<optimized out>) at eval.c:748
>   #6  0x004148fd in scm_apply_1 (proc=0x935c80, arg1=0x896af0,
>       arg1@entry=0x89c6f0, args=0x37ff828, args@entry=0x37ff830) at eval.c:588
>   #7  0x0043139b in scm_throw (key=0x89c6f0, args=0x37ff830) at throw.c:104
>   #8  0x00431819 in scm_ithrow (key=key@entry=0x89c6f0, args=0x37ff830,
>       noreturn=noreturn@entry=1) at throw.c:441
>   #9  0x0041f507 in scm_error_scm (key=key@entry=0x89c6f0, subr=0x4,
>       message=message@entry=0x643d630, args=args@entry=0x37ff850,
>       data=data@entry=0x37ff870) at error.c:95
>   #10 0x0041f577 in scm_error (key=0x89c6f0, subr=subr@entry=0x0,
>       message=message@entry=0x4dd99c <scm_eval_string_in_module__name_string_stringbuf+72> "~A", args=0x37ff850, rest=rest@entry=0x37ff870) at error.c:62
>   #11 0x0041f5fa in scm_syserror (subr=subr@entry=0x0) at error.c:167
>   #12 0x00432fe3 in scm_spawn_thread (
>       body=body@entry=0x436340 <signal_delivery_thread>,
>       body_data=body_data@entry=0x0, handler=0x431794 <scm_handle_by_message>,
>       handler_data=handler_data@entry=0x4e5a60 <scm_i_open_file__name_string_stringbuf+20>) at threads.c:1139
>   #13 0x00436318 in start_signal_delivery_thread () at scmsigs.c:200
>   #14 0x6248b751 in pthread_once () from d:\usr\bin\pthreadGC2.dll
>   #15 0x0043641c in scm_i_ensure_signal_delivery_thread () at scmsigs.c:212
>   #16 0x00432c00 in do_thread_exit (v=0x8d0f00) at threads.c:671
>   #17 0x0045f8ac in c_body (d=0x28f6a0) at continuations.c:511
>   #18 0x00454b8b in vm_regular_engine (vm=0x935c80, program=0x8f5d90,
>       argv=0xa010a4, nargs=5121210) at vm-i-system.c:855
>   #19 0x004145f8 in scm_call_4 (proc=0x896b28, arg1=arg1@entry=0x404,
>       arg2=arg2@entry=0x643d730, arg3=arg3@entry=0x643d720,
>       arg4=arg4@entry=0x643d710) at eval.c:507
>   #20 0x004312a2 in scm_catch_with_pre_unwind_handler (key=0x404,
>       thunk=0x643d730, handler=0x643d720, pre_unwind_handler=0x643d710)
>       at throw.c:86
>   #21 0x0043143e in scm_c_catch (tag=tag@entry=0x404, body=0x643d730,
>       body@entry=0x45f89c <c_body>, body_data=0x643d720,
>       body_data@entry=0x28f6a0, handler=0x643d710,
>       handler@entry=0x45fb50 <c_handler>,
>       handler_data=handler_data@entry=0x28f6a0,
>       pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=pre_unwind_handler_data@entry=0x935c40) at throw.c:213
>   #22 0x0045ff3b in scm_i_with_continuation_barrier (
>       body=body@entry=0x45f89c <c_body>, body_data=body_data@entry=0x28f6a0,
>       handler=handler@entry=0x45fb50 <c_handler>,
>       handler_data=handler_data@entry=0x28f6a0,
>       pre_unwind_handler=pre_unwind_handler@entry=0x45f9bc <pre_unwind_handler>, pre_unwind_handler_data=0x935c40) at continuations.c:449
>   #23 0x0045ffcc in scm_c_with_continuation_barrier (
>       func=0x432bf0 <do_thread_exit>, data=0x8d0f00) at continuations.c:545
>   #24 0x00431df4 in with_guile_trampoline (data=0x28f790) at threads.c:890
>   #25 0x709cffa0 in ?? () from d:\usr\bin\libgc-1.dll
>   #26 0x004326dc in with_gc_active (data=0x28f790,
>       func=0x431ddc <with_guile_trampoline>) at threads.c:238
>   #27 with_guile_and_parent (base=0x28f768, data=0x28f790) at threads.c:936
>   #28 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
>   #29 0x004328e0 in scm_i_with_guile_and_parent (parent=<optimized out>,
>       data=0x8d0f00, func=0x432bf0 <do_thread_exit>) at threads.c:951
>   #30 scm_with_guile (func=0x432bf0 <do_thread_exit>, data=0x8d0f00)
>       at threads.c:957
>   #31 0x709cae6f in ?? () from d:\usr\bin\libgc-1.dll
>   #32 0x00431e66 in on_thread_exit (v=0x8d0f00) at threads.c:754
>   #33 0x62481f14 in ptw32_callUserDestroyRoutines ()
>      from d:\usr\bin\pthreadGC2.dll
>   #34 0x624855a1 in pthread_win32_thread_detach_np ()
>      from d:\usr\bin\pthreadGC2.dll
>   #35 0x62485a45 in DllMain@12 () from d:\usr\bin\pthreadGC2.dll
>   #36 0x624810ed in DllMainCRTStartup@12 () from d:\usr\bin\pthreadGC2.dll
> 
> What's more, after this backtrace is displayed, guile hangs here:
> 
>      void
>      scm_i_close_signal_pipe()
>      {
>        /* SIGNAL_DELIVERY_THREAD_MUTEX is only locked while the signal delivery
> 	  thread is being launched.  The thread that calls this function is
> 	  already holding the thread admin mutex, so if the delivery thread hasn't
> 	  been launched at this point, it never will be before shutdown.  */
>  >>>>> scm_i_pthread_mutex_lock (&signal_delivery_thread_mutex);
> 
>      #if SCM_USE_PTHREAD_THREADS
>        if (scm_i_signal_delivery_thread != NULL)
> 	 close (signal_pipe[1]);
>      #endif
> 
>        scm_i_pthread_mutex_unlock (&signal_delivery_thread_mutex);
>      }
> 
> The backtrace is displayed before that, probably from a different
> thread, because I also tried to step through the code that eventually
> comes to scm_i_close_signal_pipe, and that didn't go through the
> function shown above that displays the Guile backtrace.
> 
> Now, I know almost nothing about pthreads.  Any ideas or suggestions
> for further debugging are most welcome.
> 
> P.S.  Should we talk about this on bug-guile instead?
> 
>