Re: ptrace single-stepping change breaks Wine

From: Jesse Allen (the3dfxdude_at_gmail.com)
Date: 11/20/04

  • Next message: Zoltan Sutto: "2.4.28 module compile problem" 
    Date:	Sat, 20 Nov 2004 14:49:15 -0700
To: Linus Torvalds <torvalds@osdl.org>

    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Zoltan Sutto: "2.4.28 module compile problem"

    Relevant Pages

    • Re: Handling Ctrl-Break quickly and efficiently in a Windows GUI app
      ... my program is busy, I display the hourglass cursor and allow them to click ... Is there a clean way for a Windows GUI app to get notified of Ctrl-Break? ... Is there a way to set a signal handler, or scan the entire message queue, ...
      (microsoft.public.win32.programmer.ui)
    • Re: ptrace single-stepping change breaks Wine
      ... > separate ptrace operation. ... breakpoint on the return point (possibly by modifying the signal handler ... It's not like single-stepping into the signal handler in any way removes ... - it the app sets TF _and_ you ptrace it, you the ptracer will see the ...
      (Linux-Kernel)
    • Re: Why would a kill -2 not work?
      ... Python app with a signal handler configured to catch INT signals. ... but we've recently noticed that after the app has run for a while the kill -2 no longer works. ... The amount of stuff you're allowed to do safely in a signal handler is pretty minimal-- you're better off setting a flag, returning from the signal handler, and having the next run past the main event loop or whatever check for the flag and handle things in a normal app context. ...
      (freebsd-questions)
    • bluephone
      ... Instaletin went fine, but starting up the app is not easy, it keeps ... The debug info did not help me much, but there might be someone out there ...
      (comp.os.linux.questions)
    • Re: ptrace single-stepping change breaks Wine
      ... >> I'm getting the feeling that the question of whether to step into ... >> separate ptrace operation. ... > breakpoint on the return point (possibly by modifying the signal handler ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)