Re: ptrace single-stepping change breaks Wine

[Jesse Allen <the3dfxdude@gmail.com>]

On Fri, Nov 19, 2004 at 01:53:38PM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 19 Nov 2004, Daniel Jacobowitz wrote:
> > 
> > I'm getting the feeling that the question of whether to step into
> > signal handlers is orthogonal to single-stepping; maybe it should be a
> > separate ptrace operation.
> 
> I really don't see why. If a controlling process is asking for 
> single-stepping, then it damn well should get it. It it doesn't want to 
> single-step through a signal handler, then it could decide to just put a 
> breakpoint on the return point (possibly by modifying the signal handler 
> save area).
> 
> It's not like single-stepping into the signal handler in any way removes 
> any information (while _not_ single-stepping into it clearly does).
> 
> With the patch I just posted (assuming it works for people), Wine should 
> at least have the choice. The behaviour now should be:
> 
>  - if the app sets TF on its own, it will cause a SIGTRAP which it can 
>    catch.
>  - if the debugger sets TF with SINGLESTEP, it will single-step into a 
>    signal handler.
>  - it the app sets TF _and_ you ptrace it, you the ptracer will see the 
>    debug event and catch it. However, doing a "continue" at that point
>    will remove the TF flag (and always has), the app will normally then
>    never see the trap. You can do a "signal SIGTRAP" to actually force
>    the trap handler to tun, but that one won't actually single-step (it's 
>    a "continue" in all other senses).
> 
> It sounds like the third case is what wine wants.
> 
> 		Linus


So an app running through wine could set TF on it's own?  It would be a 
good idea to find out what it is doing in the first place.  There has to be
a reason why War3 is so picky after the original change was introduced and
a reason why the latest changes don't seem to fix it. 

I've built a kernel 2.6.10-rc2 with the new ptrace patch.  The program still
says "please insert disc".  I haven't been able to get winedbg to tell me 
anything useful -- the program never crashes anyways.  So I went ahead and I 
captured a debug log.

the command:
WINEDEBUG=+all wine war3/Warcraft\ III.exe -opengl >& war3_and_2.6.10-rc2.log

I scanned for the part right before it calls up to display the error.  I found
that after loading advapi32.dll, the thread 000c creates a mutex and wakes up
000a.  Then 000c gets killed and right after that starts calling up the 
resources for the "insert disc" message box.  I put the log up on my ftp, and 
the interesting part in a seperate file:
ftp://resnet.dnip.net/

Any clue on what may be happening here?  Or maybe another idea on where else to search?


Jesse