No subject

--- 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

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.