Need help debugging ...

Mike Hearn mike at theoretic.com
Thu Jan 15 06:19:26 CST 2004


On Thu, 15 Jan 2004 01:00:32 +0100, Frank Schruefer wrote:
> Hey list,
> 
> I like to learn how to fix wine problems myself and am trying to track down an exception
> occuring while starting good old 'Dungeon Keeper'.

Good luck! Please don't be discouraged if you can't crack this one though,
both me and Lionel have looked at Dungeon Keeper (1 and 2) and couldn't
figure out why it doesn't work. Lionel has been a Wine hacker for 5+ years
now! If you can't get DK to work, or are finding it too
frustrating, perhaps move on to another program and see if it's any easier?

> For now I have two problems:
> 1. When I invoke the game with 'wine' and with 'winedbg' I get different exception messages
>     (traces see below), why?

You don't, you get the same crash:

from just wine:
> Unhandled exception: page fault on write access to 0x00000000 in 32-bit
> code (00406062).

from winedbg:

> First chance exception: page fault on write access to 0x00000000
> in 32-bit code (0x00406062).

Unhandled vs first chance, hmm, how to explain this. Well in the debugger
you can trap *all* exceptions, even if the program itself may in turn
catch that exception and deal with it. So it's called a first-chance
because you the debugger get the first chance to deal with it. Unhandled
just means there was an exception and the program didn't do anything with
it, so it falls back to the debugger (in Windows you would see the crash
dialog). Notice how the numbers are the same, and the fault (writing to
null) is the same.

You can disassemble this code to see what caused the crash using "disas
0x406062" but I seem to remember the results were inconclusive - as they
often are with disassembly.

> 2. How to compile debug information into the 32bit DLL's so I don't get
>     'No debug information in 32bit DLL' anymore and maybe some better info?
>     I tried 'configure --enable-debug && make depend && make && su -c "make install"' to
>     no avail.

They have debugging info in, but unfortunately there has been breakage in
the debugger recently which has not yet been fixed in CVS. This is very
bad :( EricP sent a patch here which works great for me and fixed all my
debugger problems, try looking in the archives for Jan and December
looking for it (it was sent to wine-devel not wine-patches iirc).

For now try setting WINELOADER to the path to your actual wine binary
(wine-pthread)

Eric, could you please submit that patch? Even if it's not correct, having
the debuggers out of action like this is causing big problems.

> I compiled 'fixme's into the 'SetThreadExecutionState' and 'VerSetConditionMask' funcs to
> see where the exceptions occure but it seems the methods aren't even called at all because
> the messages don't get printed out (or need the fixme messages switched on somewhere for
> that particular dll?).

No, they aren't called, they just happen to be the closest exported
symbols the debugger could find. In general the names given to you when
there are no debug symbols are useless. Look:

1 0x40501e3d (KERNEL32.DLL.SetThreadExecutionState+0x17fd in KERNEL2.DLL)

see the +0x17fd here? That means the crash occurred in some code a long
way from the start of that function, who knows where without debug symbols
though.

> I also tried to start with --debugmsg +all in which case the output is overwriting the
> winedbg command line interface and crashing it when trying to exit with CTRL-C
> and CTRL-D. Only killall -9 wine-pthread helps then.

Redirect the output to a logfile:

wine --debugmsg +all keeper.exe 2>log

Useful channels are +relay which show every API call, +snoop which does
the same but between non-wine DLLs (so it's a bit crashy but should be
fine here) and so on.

IIRC keeper makes only one or two API calls before crashing, both of those
calls are trivial and succeed (setting a timer or something I think) so
it's more likely to be to do with the layout of an in memory struct or
something. Remember that the TEB is stored in %fs, if you see references
to that register.

> The wine I'm using is fresh from CVS as of 15. Jan. 2004 but I had the problem with earlier
> versions too.

Yes, keeper has never worked for me :(

thanks -mike




More information about the wine-devel mailing list