Wierd wine threading crash

[Andrei Barbu]

I'm trying to get Alpha Centauri working on wine.
I've fixed some bugs, but I've hit a wall with this one:

0011:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4fb13f
0011:trace:seh:EXC_RtlRaiseException  info[0]=00000000
0011:trace:seh:EXC_RtlRaiseException  info[1]=00a63834
0011:trace:seh:EXC_RtlRaiseException  eax=000362a2 ebx=00000001 ecx=00000001
edx=00000000 esi=00000000 edi=00000320
0011:trace:seh:EXC_RtlRaiseException  ebp=4073a920 esp=40738a98 cs=0073 ds=007b
es=007b fs=0033 gs=0007 flags=00010246

First chance exception: page fault on read access to 0x00a63834 in 32-bit code
(0x004fb13f).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0007
 EIP:004fb13f ESP:40738a98 EBP:4073a920 EFLAGS:00010246(   - 00      -RIZP1)
 EAX:000362a2 EBX:00000001 ECX:00000001 EDX:00000000
 ESI:00000000 EDI:00000320
Stack dump:
0x00000000:  00000000 00000000 00000000 00000000
0x00000010:  00000000 00000000 00000000 00000000
0x00000020:  00000000 00000000 00000000 00000000
0x00000030:  00000000 00000000 00000000 00000000
0x00000040:  00000000 00000000 00000000 00000000
0x00000050:  00000000 00000000 00000000 00000000
0x00000060:

Backtrace:
=>1 0x004fb13f (0x4073a920)
  2 0x004e5cd0 (0x4073a94c)
  3 0x004ef883 (0x4073fda4)
  4 0x004f5ae1 (0x4073fdc0)
  5 0x005206d8 (0x4073fde0)
  6 0x0052091f (0x4073fe00)
  7 0x00520d07 (0x4073fe1c)
  8 0x00522a1b (0x4073fe90)
  9 0x0064dd06 (0x4073ff20)
  10 0x4057f352 start_process+0xf2(arg=0x0) [process.c:980] in kernel32 (0x4073fff4)
  11 0x40044091 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000)
0x004fb13f: movb        0x98adac(,%eax,4),%dl

The error happens regularly every time the 1st turn is ended (it's
turn based, which makes things simpler in this case)

Any ideas?
By the way, the above only happens once in a while, it's more common
for the stack to be full of ??s or winedbg failing to get any backtraces.

[Mike Hearn]

On Sun, 04 Jul 2004 03:11:48 -0400, Andrei Barbu wrote:
> Any ideas?
> By the way, the above only happens once in a while, it's more common
> for the stack to be full of ??s or winedbg failing to get any backtraces.

Yeah. I wouldn't pay too much attention to what winedbg is saying
currently, the move to dbghelp seems to have broken a few things. I wasted
an hour or two the other day because winedbg was giving an identical
backtrace for each thread in a process - it was only after examining the
logs that I realised it was actually just silently backtracing the same
thread each time. I'm sure these bugs will be shaken out sooner or later
but for now I'd go by the contents of the traces alone.

In this case, I'd suggest doing a +relay,+seh trace and seeing what was
invoked just before the crash: the winedbg disassembler should still be
working as well if you want to try and find out what the program was doing
at the time of the crash.

thanks -mike