http://bugs.winehq.org/show_bug.cgi?id=21636
--- Comment #6 from Anastasius Focht focht@gmx.net 2010-02-10 15:15:50 --- Hello,
unfortunately I can't reproduce it here. What kind of system are you on?
$ uname -a
$ /lib/libc.so.6
$ winegcc -v
Please provide additional server trace (make sure no lingering wineserver process exists prior):
WINEDEBUG=+tid,+seh,+loaddll,+process,+server wine ./MJ12node.exe >>trace.txt 2>&1
Terminate wineserver externally (wineserver -k) when you get the freeze.
---
The snippet where this occurs is always the same sequence:
From log2 (threads 0x2f gets nested sigs while being suspended):
--- snip --- ... 0009:Call KERNEL32.CreateThread(00000000,00000000,79ecafc5,001dbcd0,00000004,0033ea00) ret=79ecaf77 ... 0009:Ret KERNEL32.CreateThread() retval=00000258 ret=79ecaf77 ... 0039:Call KERNEL32.SuspendThread(00000258) ret=79f6e649 0039:Ret KERNEL32.SuspendThread() retval=00000000 ret=79f6e649 002f:err:seh:setup_exception_record nested exception on signal stack in thread 002f eip 7bc73480 esp 7ffbfc3c stack 0x7712000-0x7810000 0039:Call KERNEL32.GetThreadContext(00000258,0657e588) ret=79f6e75f 0039:Ret KERNEL32.GetThreadContext() retval=00000000 ret=79f6e75f 0039:Call KERNEL32.ResumeThread(00000258) ret=7a0dc002 0039:Ret KERNEL32.ResumeThread() retval=00000001 ret=7a0dc002 ... --- snip ---
From log3 (threads 0x28 and 0x31 get nested sigs while being suspended):
--- snip --- 0033:Call KERNEL32.CreateThread(00000000,00000000,79ecafc5,001db2f0,00000004,03b6e894) ret=79ecaf77 ... 0033:Ret KERNEL32.CreateThread() retval=00000238 ret=79ecaf77 ... 000b:Call KERNEL32.SuspendThread(00000238) ret=79f6e649 000b:Ret KERNEL32.SuspendThread() retval=00000000 ret=79f6e649 0028:err:seh:setup_exception_record nested exception on signal stack in thread 0028 eip 7bc73480 esp 7ffbfc3c stack 0x7672000-0x7770000 000b:Call KERNEL32.GetThreadContext(00000238,0572e588) ret=79f6e75f 000d:Call KERNEL32.GetLastError() ret=79e74ade 000d:Ret KERNEL32.GetLastError() retval=000003e5 ret=79e74ade 000d:Call KERNEL32.SetLastError(000003e5) ret=79e74af7 000d:Ret KERNEL32.SetLastError() retval=000003e5 ret=79e74af7 000d:Call KERNEL32.SetLastError(000003e5) ret=79e74aca 000d:Ret KERNEL32.SetLastError() retval=000003e5 ret=79e74aca 000d:Call KERNEL32.WaitForSingleObjectEx(000000d4,ffffffff,00000000) ret=79e77fd1 000b:Ret KERNEL32.GetThreadContext() retval=00000000 ret=79f6e75f 000b:Call KERNEL32.ResumeThread(00000238) ret=7a0dc002 000b:Ret KERNEL32.ResumeThread() retval=00000001 ret=7a0dc002 ... 000b:Call KERNEL32.SuspendThread(0000034c) ret=79f6e649 000b:Ret KERNEL32.SuspendThread() retval=00000000 ret=79f6e649 0031:err:seh:setup_exception_record nested exception on signal stack in thread 0031 eip 7bc73480 esp 7ffa7c3c stack 0x68a2000-0x69a0000 000b:Call KERNEL32.GetThreadContext(0000034c,0572e588) ret=79f6e75f 000b:Ret KERNEL32.GetThreadContext() retval=00000000 ret=79f6e75f 000b:Call KERNEL32.ResumeThread(0000034c) ret=7a0dc002 000b:Ret KERNEL32.ResumeThread() retval=00000001 ret=7a0dc002 ... --- snip ---
Since bug 10338 the thread signal stack has been increased to 16K minimum which ought to be enough.
The API call sequence SuspendThread() + GetThreadContext() is to make sure the target (remote) thread is really stopped to access critical data structures (that might be manipulated if the target thread would be still running). I remember having read SuspendThread() queues an APC for the target (remote) thread so it is not guaranteed that a user thread is really stopped after the call returns (especially true on multi-processor machines) - hence the additional GetThreadContext().
Now the question is what goes wrong that lets the signal stack get eaten up... might be even broken kernel+glibc combo.
Regards