Re: GNU Guile 2.0.10 released

[Panicz Maciej Godek]

2014-03-20 9:04 GMT+01:00 Ludovic Courtès <address@hidden>:
> Panicz Maciej Godek <address@hidden> 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 address@hidden 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 address@hidden

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.