Hallo,
since some time for me the debugger doesn't start when a program crashes. As there was a lot of reorganization, my non-standard setup (try to run wine in place) and due to lack of time to verify (workload, holidays) I can't tell when exactly the breackage occured.
The exception (here in a simple test program, doing an int21 in 32 bit mode), the exception is thrown.
win32/exception.c:start_debugger_atomic() creates the event 088f7250: queue_exception_event() = 0 { handle=0 } 088f7250: create_event( manual_reset=1, initial_state=0, inherit=1, name=L"") 088f7250: create_event() = 0 { handle=100 } wine: Unhandled exception, starting debugger... ...
The event-handle is passed to the winedbg command line: trace:seh:start_debugger Starting debugger format_size 58 (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined bg %ld %ld) trace:seh:start_debugger h:\tmp\wine\compile\wine\programs\winedbg\winedbg 134683568 100 088f7250: *signal* signal=14 088f7250: create_file( access=80000000, inherit=0, sharing=00000001,create=3, attrs=00000000, drive_type=4, f ...
We select on that handle: 088f7250: select( flags=4, cookie=0x412d05e0, sec=0, usec=0, handles={100} ) ...
After winedbg startup, winedbg tries to set this event 088f75a0:Ret kernel32.DebugActiveProcess() retval=00000001 ret=404e1f04 088f75a0:Call kernel32.SetEvent(00000064) ret=404e33b6 088f75a0: event_op( handle=100, op=1 ) 088f75a0: event_op() = INVALID_HANDLE 088f75a0:Ret kernel32.SetEvent() retval=00000000 ret=404e33b6
but the event is invalid and winedbg shuts down immediately:
088f75a0:Call kernel32.ExitProcess(00000000) ret=404ca18f
Any idea, what's going wrong?
Bye
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
The event-handle is passed to the winedbg command line: trace:seh:start_debugger Starting debugger format_size 58 (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined bg %ld %ld) trace:seh:start_debugger h:\tmp\wine\compile\wine\programs\winedbg\winedbg 134683568 100
The problem is that your debugger path points to a Unix script, and the new exe loadorder support no longer starts Winelib apps that way. The winedbg script should be used only when starting from the Unix command line, from inside Wine you need to specify a .exe or .exe.so instead. If your WINEDLLPATH is set correctly (which should be the case when running inside the source tree) you should be able to simply use "winedbg.exe" without any path.
"Alexandre" == Alexandre Julliard julliard@winehq.com writes:
Alexandre> Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes: >> The event-handle is passed to the winedbg command line: >> trace:seh:start_debugger Starting debugger format_size 58 >> (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined bg %ld %ld) >> trace:seh:start_debugger >> h:\tmp\wine\compile\wine\programs\winedbg\winedbg 134683568 100
Alexandre> The problem is that your debugger path points to a Unix Alexandre> script, and the new exe loadorder support no longer starts Alexandre> Winelib apps that way. The winedbg script should be used only Alexandre> when starting from the Unix command line, from inside Wine Alexandre> you need to specify a .exe or .exe.so instead. If your Alexandre> WINEDLLPATH is set correctly (which should be the case when Alexandre> running inside the source tree) you should be able to simply Alexandre> use "winedbg.exe" without any path.
Thanks, that did the trick.
Bye
On September 29, 2002 01:54 pm, Alexandre Julliard wrote:
The problem is that your debugger path points to a Unix script, and the new exe loadorder support no longer starts Winelib apps that way.
That's very unfortunate, as it is extremely counterintuitive. To the point where *I* gave up on using the debugger. A developer. What about users? We'll have to explain weird technical reasons: that's a winelib app, that's PE executable, etc. This sucks. Wine should seamlessly integrate all these executables together. A user should not care about the actual type of executable, it should just be able to run the dang thing.
"Dimitrie O. Paun" dpaun@rogers.com writes:
That's very unfortunate, as it is extremely counterintuitive. To the point where *I* gave up on using the debugger. A developer. What about users? We'll have to explain weird technical reasons: that's a winelib app, that's PE executable, etc. This sucks. Wine should seamlessly integrate all these executables together. A user should not care about the actual type of executable, it should just be able to run the dang thing.
But that's exactly what it does. You have problems because you know too much; with the new scheme a user doesn't even have to know that there is a way to configure the debugger, it will just work. The change only bites people who knew how it worked before and adapted their registry; so now you need to return your registry to the default state to make things work.
On September 29, 2002 10:25 pm, Alexandre Julliard wrote:
But that's exactly what it does. You have problems because you know too much; with the new scheme a user doesn't even have to know that there is a way to configure the debugger, it will just work.
It's a good thing, granted. But my comment was referring more to this:
The winedbg script should be used only when starting from the Unix command line, from inside Wine you need to specify a .exe or .exe.so instead.
This I don't like. I have to start the _same_ executable using different names! As a user, why should I even care, or know, that a window on my screen is a Unix window, or a Wine window?
If I have a "Run command..." dialog which takes the command name, why should I know (and how), that in one I should type winedbg, and in another winedbg.exe? In fact, even DOS/Windows users are used to be able to specify the probram name _without_ the .exe/.bat/.cmd/.com/etc. extension. Why should they do any different in Wine?
I haven't looked at the problem at all to understand the technical reasons behind this requirements, but I can say, as a user, that's quite counterintuitive...
"Dimitrie O. Paun" dpaun@rogers.com writes:
If I have a "Run command..." dialog which takes the command name, why should I know (and how), that in one I should type winedbg, and in another winedbg.exe? In fact, even DOS/Windows users are used to be able to specify the probram name _without_ the .exe/.bat/.cmd/.com/etc. extension. Why should they do any different in Wine?
They shouldn't. In almost all cases it will be completely transparent; BTW "winedbg" works the same as "winedbg.exe", it's the explicit path that is the problem. If you explicitly specify a full path to a Unix script it will be launched as a Unix script. This will work fine, even if the script starts a Winelib app, except if the app depends on inheriting handles from the parent process, which is a *very* uncommon case.
I believe the current behavior is a good compromise between being Windows compatible and allowing to launch Unix apps. Some improvements may be possible, but make sure you really understand how it works first; the behavior is quite complex, precisely because we try to always do the right thing.
On September 30, 2002 12:57 am, Alexandre Julliard wrote:
This will work fine, even if the script starts a Winelib app, except if the app depends on inheriting handles from the parent process, which is a *very* uncommon case.
And I gather that winedbg is just such a case...
I believe the current behavior is a good compromise between being Windows compatible and allowing to launch Unix apps. Some improvements may be possible, but make sure you really understand how it works first; the behavior is quite complex, precisely because we try to always do the right thing.
So it seems, thank you for the explanation. I have no intention of fiddling with this stuff, don't worry :). It just seemed that your explanation applied to all winelib apps, and that worried my a little. ;)
-
Alexandre Julliard -
Dimitrie O. Paun -
Uwe Bonnes