[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Guile 2.0.10 released
From: |
Eli Zaretskii |
Subject: |
Re: GNU Guile 2.0.10 released |
Date: |
Wed, 26 Mar 2014 20:24:01 +0200 |
> Date: Thu, 20 Mar 2014 11:34:53 +0100
> From: Panicz Maciej Godek <address@hidden>
> Cc: address@hidden, "address@hidden" <address@hidden>
>
> >> I did remove the only reference to mkstemp.c that appeared in the
> >> Makefile.am, then run autoreconf and configure, but it turned out that
> >> there were still some dependencies on libguile_2.0_la-mkstemp.o in the
> >> generated libguile/Makefile. After removing those, I went through that
> >> part of compilation, but the process stalled on the GEN
> >> guile-procedures.texi.
> >
> > OK. How long did you wait? That part can take a bit of time (I'd say
> > 30s to 1mn maybe) because it runs the yet-to-be-compiled Guile.
>
> I decided to run the whole process once again, and GEN
> guile-procedures.texi has been running for almost an hour now, and it
> clearly uses no CPU.
>
> I had a "process hacker" tool installed, and it allows me to do some
> introspection (although I understand very little). There are two
> threads running in the "youngest" guile.exe (#2820), the first one
> with start address
> guile.exe+0x1570
> and the second with
> msvcrt.dll!endthreadex+0x3a
>
> When I inspect the first thread, I get:
>
> 0, ntkrnlpa.exe!KiDeliverApc+0xb3
> 1, ntkrnlpa.exe!ZwYieldExecution+0x19ae
> 2, ntkrnlpa.exe!NtWaitForSingleObject+0x38c
> 3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
> 4, ntdll.dll!KiFastSystemCallRet
> 5, kernel32.dll!WaitForMultipleObjects+0x18
> 6, pthreadGC2.dll!pthreadCancelableTimedWait+0x4b
> 7, pthreadGC2.dll!sem_timedwait+0x16f
> 8, 0x79a50
>
> The inspection of the second thread shows:
>
> 0, ntkrnlpa.exe!KiDeliverApc+0xb3
> 1, ntkrnlpa.exe!ZwYieldExecution+0x19ae
> 2, ntkrnlpa.exe!NtWaitForSingleObject+0x9a
> 3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
> 4, ntdll.dll!KiFastSystemCallRet
> 5, ntdll.dll!RtlEnterCriticalSection+0x46
> 6, ntdll.dll!KiUserApcDispatcher+0x7
>
> When I use the "analyze > wait" option on the first thread, I get:
> Thread is waiting (alertable, wait all) for:
> Handle 0x79a50 (Semaphore): (unnamed object)
> Handle 0x7b4 (Event): (unnamed object)
Isn't this the same problem I reported last year, starting here:
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00022.html
I suggest to configure Guile --without-threads, and see if that
resolves the issue.
- GNU Guile 2.0.10 released, Ludovic Courtès, 2014/03/17
- Re: GNU Guile 2.0.10 released, Andy Wingo, 2014/03/18
- Re: GNU Guile 2.0.10 released, Panicz Maciej Godek, 2014/03/19
- Re: GNU Guile 2.0.10 released, Ludovic Courtès, 2014/03/19
- Re: GNU Guile 2.0.10 released, Mark H Weaver, 2014/03/19
- Re: GNU Guile 2.0.10 released, Panicz Maciej Godek, 2014/03/19
- Re: GNU Guile 2.0.10 released, Ludovic Courtès, 2014/03/20
- Re: GNU Guile 2.0.10 released, Panicz Maciej Godek, 2014/03/20
- Re: GNU Guile 2.0.10 released,
Eli Zaretskii <=
- Re: GNU Guile 2.0.10 released, Panicz Maciej Godek, 2014/03/26
- Re: GNU Guile 2.0.10 released, Mike Gran, 2014/03/26
- Re: GNU Guile 2.0.10 released, Eli Zaretskii, 2014/03/26
- Re: GNU Guile 2.0.10 released, Ludovic Courtès, 2014/03/27
- Re: GNU Guile 2.0.10 released, Eli Zaretskii, 2014/03/26
- Re: GNU Guile 2.0.10 released, Panicz Maciej Godek, 2014/03/26
- Re: GNU Guile 2.0.10 released, Mark H Weaver, 2014/03/30