Hang in usr1_handler (ptrace issue?)

[Mike Hearn]

On Mon, 06 Dec 2004 18:23:28 +0000, Mike Hearn wrote:
> Lately I've been seeing hangs of this form:
> 
> Backtrace:
> =>1 0x4df8e7a2 (0x659ffb54)
>   2 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x0, handles=0x0, flags=0x8, timeout=0x659ffd10) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x659ffcf8)
>   3 0x5246da88 usr1_handler+0x38(__signal=0xa, __context=0x33) [/source/wine/dlls/ntdll/signal_i386.c:1159] in ntdll (0x659ffd1c)
>   4 0x100238a8 (0x65bfc6cc)
>   5 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x1, handles=0x65bfc8bc, flags=0x4, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x65bfc870)
>   6 0x5246f5df NtWaitForMultipleObjects+0x4b(count=0x1, handles=0x65bfc8bc, wait_all=0x0, alertable=0x0, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:713] in ntdll (0x65bfc898)
>   7 0x1894e4b3 WaitForMultipleObjectsEx+0xa3(count=0x1, handles=0x65bfc9f0, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [/source/wine/dlls/kernel/sync.c:180] in kernel32 (0x65bfc9c8)
> 
> in other words, whilst waiting on some server object it was suspended. 

Never mind, I'm an idiot. Winedbg does a SuspendThread on the target
before getting a backtrace and so you see the signal stack as a part of
the backtrace even though it's not a part of the "real" thread stack.

A bit confusing but no big deal. Maybe dbghelp should suppress these
frames.

thanks -mike