From: Eli Zaretskii <eliz@gnu.org>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-user@gnu.org
Subject: Re: guile 2.0.9 build on mingw
Date: Wed, 22 May 2013 18:26:59 +0300 [thread overview]
Message-ID: <83ip2bt4qk.fsf@gnu.org> (raw)
In-Reply-To: <874ndx9y7h.fsf@pobox.com>
> 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?
next prev parent reply other threads:[~2013-05-22 15:26 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 19:46 guile 2.0.9 build on mingw Panicz Maciej Godek
2013-05-20 20:05 ` Eli Zaretskii
2013-05-20 20:46 ` Andy Wingo
2013-05-20 21:09 ` objc
2013-05-21 2:43 ` Eli Zaretskii
2013-05-22 15:26 ` Eli Zaretskii [this message]
2013-06-07 8:37 ` Eli Zaretskii
2013-06-07 12:44 ` Ludovic Courtès
2013-06-07 14:59 ` Eli Zaretskii
2013-06-09 17:10 ` Eli Zaretskii
2013-06-09 20:33 ` Ludovic Courtès
2013-06-09 21:16 ` Andy Wingo
2013-06-09 21:35 ` Ludovic Courtès
2013-06-10 16:18 ` Eli Zaretskii
2013-06-10 16:18 ` Eli Zaretskii
2013-06-10 16:23 ` Eli Zaretskii
2013-06-10 19:09 ` Mark H Weaver
2013-06-10 19:49 ` Eli Zaretskii
2013-06-10 20:54 ` Mark H Weaver
2013-06-11 16:53 ` Eli Zaretskii
2013-06-11 22:11 ` Ludovic Courtès
2013-06-12 17:46 ` Eli Zaretskii
2013-06-18 21:51 ` Why launch the Guile signal delivery thread on exit? (was Re: guile 2.0.9 build on mingw) Mark H Weaver
2013-06-19 15:51 ` Eli Zaretskii
2013-06-19 16:06 ` Julian Graham
2013-06-19 19:20 ` Ludovic Courtès
2013-06-12 17:57 ` guile 2.0.9 build on mingw Eli Zaretskii
2013-06-13 13:26 ` Eli Zaretskii
2013-06-16 14:19 ` Ludovic Courtès
2013-06-13 13:33 ` Eli Zaretskii
2013-06-16 14:36 ` Ludovic Courtès
2013-06-16 15:40 ` Eli Zaretskii
2013-06-16 14:55 ` Ludovic Courtès
2013-06-16 15:47 ` Eli Zaretskii
2013-06-16 18:59 ` Ludovic Courtès
2013-06-13 13:40 ` Eli Zaretskii
2013-06-16 14:59 ` Ludovic Courtès
2013-06-17 15:41 ` Eli Zaretskii
2013-06-18 20:45 ` Ludovic Courtès
2013-06-18 22:28 ` Mark H Weaver
2013-06-19 3:03 ` Eli Zaretskii
2013-06-19 19:26 ` Ludovic Courtès
2013-06-19 20:02 ` Eli Zaretskii
2013-06-19 2:59 ` Eli Zaretskii
2013-06-19 15:56 ` Eli Zaretskii
2013-06-19 19:38 ` Ludovic Courtès
2013-06-13 13:41 ` Eli Zaretskii
2013-06-16 15:04 ` Ludovic Courtès
2013-06-16 15:48 ` Eli Zaretskii
2013-06-16 14:44 ` Ludovic Courtès
2013-06-16 15:41 ` Eli Zaretskii
2013-06-12 17:59 ` Eli Zaretskii
2013-06-16 14:46 ` Ludovic Courtès
2013-06-12 18:02 ` Eli Zaretskii
2013-06-16 19:50 ` Ludovic Courtès
2013-06-16 20:22 ` Eli Zaretskii
2013-06-17 15:45 ` Mark H Weaver
2013-06-18 17:17 ` Eli Zaretskii
2013-06-18 19:31 ` Eli Zaretskii
2013-06-18 20:19 ` Ludovic Courtès
2013-06-19 2:53 ` Eli Zaretskii
2013-06-19 19:28 ` Ludovic Courtès
2013-06-19 19:56 ` Eli Zaretskii
2013-05-26 20:41 ` Panicz Maciej Godek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ip2bt4qk.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=guile-user@gnu.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).