Re: guile 2.0.9 build on mingw

[Ludovic Courtès]

Hi Eli,

And sorry for the loooong delay.

Eli Zaretskii <address@hidden> skribis:

>> From: Andy Wingo <address@hidden>
>> Cc: Panicz Maciej Godek <address@hidden>,  address@hidden
>> 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

[...]

>   #11 0x0041f5fa in scm_syserror (address@hidden) at error.c:167
>   #12 0x00432fe3 in scm_spawn_thread (
>       address@hidden <signal_delivery_thread>,
>       address@hidden, handler=0x431794 <scm_handle_by_message>,
>       address@hidden <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

That vaguely rings a bell, and there were commits in that area over the
last couple of years.

What version of Guile and libgc is it?

Did you build them with pthread support (this is the default for Guile)?

> 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);
>      }

Can you run ‘thread apply all bt’ in gdb once it’s hang, and send the
tip of the C backtraces for all the threads?

Ludo’.