29 Sep
2002
29 Sep
'02
5:25 p.m.
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(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
29 Sep
29 Sep
5:54 p.m.
Uwe Bonnes <bon(a)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 Julliard
julliard(a)winehq.com
6:50 p.m.
>>>> "Alexandre" == Alexandre
Julliard <julliard(a)winehq.com> writes:
Alexandre> Uwe Bonnes <bon(a)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
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
30 Sep
30 Sep
12:49 a.m.
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.
--
Dimi.
2:25 a.m.
"Dimitrie O. Paun" <dpaun(a)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.
--
Alexandre Julliard
julliard(a)winehq.com
3:49 a.m.
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...
--
Dimi.
4:57 a.m.
"Dimitrie O. Paun" <dpaun(a)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.
--
Alexandre Julliard
julliard(a)winehq.com
5:02 a.m.
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. ;)
--
Dimi.
7902
days inactive
7903
days old
7 comments
3 participants
participants (3)
-
Alexandre Julliard -
Dimitrie O. Paun -
Uwe Bonnes