2014-03-20 9:04 GMT+01:00 Ludovic Courtès <[email protected]>: > Panicz Maciej Godek <[email protected]> skribis: [...] >> 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) The same "analyze > wait" on the second thread results with a popup which explains that "the thread doesn't appear to be waiting". The analyzed process occupies 71,55MB and is a child process of another guile.exe process (#2120), which uses 308kB and consists of one thread, whose "wait analysis" shows: Thread is waiting (alertable) for: Handle 0x7c0 (Process): guile.exe (2820) [no surprise] It looks like it has something to do with the multithreaded bdw-gc, so I'm sending a copy of this letter to [email protected] with a mention that I'm using gc-7.2e configured with --enable-threads=posix (on mingw, of course), perhaps they might know what's going on. >> Furthermore, after pressing C-c, I had some "permission denied" error. >> (I don't know if that's the original, but after repeating the process >> with some modifications it didn't even get to the "GEN", but at the >> stage of CCLD libguile-2.0.la it produces: >> ..../mingw/bin/ld.exe: cannot open output file >> .libs/libguile-2.0.22.dll: Permission denied) > > It looks like a setup issue on the machine, no? It turned out that C-c didn't kill the process, but apparently it detached it from the terminal, and it had been occupying the resource all that time. >> BTW I had to run configure with >> ac_cv_func__set_invalid_parameter_handler=no >> because otherwise I had a "_set_invalid_parameter_handler could not be >> located in the dynamic link library msvcrt.dll" error popup. > > Hmm, do you know what that means? This actually comes from Gnulib's > 'msvc-inval' module, so it would be great if you could provide a > detailed report at [email protected]. I have found that solution here: http://mingw.5.n7.nabble.com/Building-gettext-from-source-using-GCC-4-7-2-td32229.html but I really don't know what it means, and I think I'd have to examine that in more detail before daring to send a bug report, since the issue seems to be known. Thank you, M.
