Re: GNU Guile 2.0.10 released

> Date: Thu, 20 Mar 2014 11:34:53 +0100
> From: Panicz Maciej Godek <[email protected]>
> Cc: [email protected], "[email protected]" <[email protected]>
> 
> >> 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.