guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile 2.0.9 build on mingw


From: Eli Zaretskii
Subject: Re: guile 2.0.9 build on mingw
Date: Wed, 22 May 2013 18:26:59 +0300

> 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
  #1  pre_unwind_handler (address@hidden, tag=0x89c6f0,
      address@hidden) 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,
      address@hidden, args=0x37ff828, address@hidden) at eval.c:588
  #7  0x0043139b in scm_throw (key=0x89c6f0, args=0x37ff830) at throw.c:104
  #8  0x00431819 in scm_ithrow (address@hidden, args=0x37ff830,
      address@hidden) at throw.c:441
  #9  0x0041f507 in scm_error_scm (address@hidden, subr=0x4,
      address@hidden, address@hidden,
      address@hidden) at error.c:95
  #10 0x0041f577 in scm_error (key=0x89c6f0, address@hidden,
      address@hidden <scm_eval_string_in_module__name_string_stringbuf+72> 
"~A", args=0x37ff850, address@hidden) at error.c:62
  #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
  #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, address@hidden,
      address@hidden, address@hidden,
      address@hidden) 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 (address@hidden, body=0x643d730,
      address@hidden <c_body>, body_data=0x643d720,
      address@hidden, handler=0x643d710,
      address@hidden <c_handler>,
      address@hidden,
      address@hidden <pre_unwind_handler>, address@hidden) at throw.c:213
  #22 0x0045ff3b in scm_i_with_continuation_barrier (
      address@hidden <c_body>, address@hidden,
      address@hidden <c_handler>,
      address@hidden,
      address@hidden <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 address@hidden () from d:\usr\bin\pthreadGC2.dll
  #36 0x624810ed in address@hidden () 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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]