Need help debugging ...

[Frank Schruefer]

> 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?

Hehe, ok ... but I'm not giving up yet;)

> 
> 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.

Ok, I understand.

>>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)

That works.

> 
> 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.

Ok.

> 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.

Yep. It's setting up a timer which in turn creates a thread as far as I
understand until now. There's something like a stack overflow going on _maybe_.
I've put a backtrace dumping to the start of RTLLeaveCriticalSection which shows more
than >1024 stackframes being used near the occurance of the prob - it's showing a re-
peating pattern, as does wine --debugmsg +relay,+seh.

Here a little excerpt of the latter:
...
...
...
0013:Ret  ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret  ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret  ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret  ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret  ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret  ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret  ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret  ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret  ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:RUnhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x00406062).
In 32-bit mode.
0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE): movb    $0x0,0x0(%eax)
Wine-dbg>walk thread
process  tid      prio
00000011 (D) C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE
         00000013    0
         00000012    0 <==
00000008
         00000009    0
Wine-dbg>

I've set stack_reserve to 8MB min. That didn't make much of a difference.
Unfortunitely I run across a bunch of debugger bugs (I think) following the creation
of the timer thread, I decided to put these problems into another post though.
I wanted to step to the point where the thread comes alive when the debugger left me at/near
a syscall :(
I think it has something to do with this thread cause the exception you get is always
another depending on what you currently debug ... somehow asynchronous, as the above :)

-- 
Thank you,
   Frank