Hang in usr1_handler (ptrace issue?)

[Mike Hearn]

Hi,

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. I
am running the FC3 kernel "2.6.9-1.681_FC3". Is this what the
previously discussed ptrace change would look like? If so I may need to
ask Red Hat to do an errata or something. I saw that in 2.6.10-rc3
another ptrace change went in, so it may be that it's now fixed.

thanks -mike

[Jesse Allen]

On Mon, 06 Dec 2004 18:23:28 +0000, Mike Hearn  wrote:
> Hi,
>
> 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. I
> am running the FC3 kernel "2.6.9-1.681_FC3". Is this what the
> previously discussed ptrace change would look like? If so I may need to
> ask Red Hat to do an errata or something. I saw that in 2.6.10-rc3
> another ptrace change went in, so it may be that it's now fixed.
>
> thanks -mike

This may very well be the remaining problem for Warcraft 3.  I'll
check my log again to see if there is a similarity.  If anyone wants
this log, I can send it to you -- It's 500 KB.

[Jesse Allen]

On Mon, Dec 06, 2004 at 01:19:37PM -0700, Jesse Allen wrote:
> On Mon, 06 Dec 2004 18:23:28 +0000, Mike Hearn  wrote:
> > Hi,
> >
> > Lately I've been seeing hangs of this form:

...
> > in other words, whilst waiting on some server object it was suspended. I
> > am running the FC3 kernel "2.6.9-1.681_FC3". Is this what the
> > previously discussed ptrace change would look like? If so I may need to
> > ask Red Hat to do an errata or something. I saw that in 2.6.10-rc3
> > another ptrace change went in, so it may be that it's now fixed.
> >
> > thanks -mike
>
> This may very well be the remaining problem for Warcraft 3.  I'll
> check my log again to see if there is a similarity.  If anyone wants
> this log, I can send it to you -- It's 500 KB.

I can't tell if there is any similarity cause that function doesn't show up.
If anyone wants the log it's here:
http://www.chez.com/alors/loop.log.bz2
(copy and paste url into browser, don't click, it won't work)

Anyone has any clue what is going on here?  This is still related to the 
ptrace changes.

[Mike Hearn]

On Thu, 2004-12-09 at 15:00 -0700, Jesse Allen wrote:
> I can't tell if there is any similarity cause that function doesn't show up.
> If anyone wants the log it's here:
> http://www.chez.com/alors/loop.log.bz2
> (copy and paste url into browser, don't click, it won't work)
>
> Anyone has any clue what is going on here?  This is still related to the 
> ptrace changes.

When it hangs (at 100% on the loading screen) get a backtrace using
winedbg, eg:

winedbg --command 'bt all'

and post the results here.

thanks -mike

[Jesse Allen]

On Fri, Dec 10, 2004 at 05:11:34PM +0000, Mike Hearn wrote:
> When it hangs (at 100% on the loading screen) get a backtrace using
> winedbg, eg:
>
> winedbg --command 'bt all'
>
> and post the results here.
>
> thanks -mike

Well, I've had no luck at reproducing the situation.  It may have been the 
version of wine cvs I was running at the time.  But it is failing at the cd 
check like it was originally (2.6.10-rc3).  I'll try to figure out what it's 
doing now.

Jesse

[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