http://bugs.winehq.org/show_bug.cgi?id=12322
--- Comment #1 from Jeff Layton jlayton@poochiereds.net 2008-04-01 21:03:28 --- I've done my share of kernel debugging, so I can poke at this a bit...
Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x00408dd2). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00408dd2 ESP:0033fd40 EBP:0033fe6c EFLAGS:00010202( - 00 - -RI1) EAX:00000000 EBX:00000000 ECX:00000001 EDX:60ff7250 ESI:00000000 EDI:00000001 Stack dump: 0x0033fd40: 004c7ef4 004c7c30 00000000 00408552 0x0033fd50: 14002df0 0040a6fe 7ffdf000 001110ff 0x0033fd60: 00000000 535c3a43 69726361 65636966 0x0033fd70: 63615300 69666972 652e6563 60006578 0x0033fd80: 00110048 602f1a51 00000408 0000008c 0x0033fd90: 00113368 602f13cf 004c6064 6077c2dc Backtrace: =>1 0x00408dd2 in sacrifice (+0x8dd2) (0x0033fe6c) 2 0x004be6c6 in sacrifice (+0xbe6c6) (0x0033ff08) 3 0x60413e2e in kernel32 (+0x53e2e) (0x0033ffe8) 4 0x60039757 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x00408dd2: movl 0x0(%ecx),%eax
...here's the disassembly around that address:
408dbf: 90 nop 408dc0: 8b 0d 18 a9 4d 00 mov 0x4da918,%ecx 408dc6: 6a 00 push $0x0 408dc8: 68 30 7c 4c 00 push $0x4c7c30 408dcd: 68 f4 7e 4c 00 push $0x4c7ef4 408dd2: 8b 01 mov (%ecx),%eax <<<< crash here 408dd4: ff 50 30 call *0x30(%eax) 408dd7: 85 c0 test %eax,%eax 408dd9: 74 15 je 0x408df0 408ddb: 8b 0d e8 f5 4b 00 mov 0x4bf5e8,%ecx 408de1: 68 d8 7e 4c 00 push $0x4c7ed8 408de6: 51 push %ecx 408de7: ff 15 c0 f5 4b 00 call *0x4bf5c0 408ded: 83 c4 08 add $0x8,%esp 408df0: c3 ret 408df1: 90 nop
...so the bizarre thing here is that the stack looks correct for all of the pushes leading up to the mov that fails. For some reason though, %ecx did not contain 0x4da918.
So either we got here by jumping to 0x408dc6 or something clobbered %ecx. The only explicit jmp I see to that area is to 0x408dc0:
40854d: e8 6e 08 00 00 call 0x408dc0 <<< here 408552: 68 38 7c 4c 00 push $0x4c7c38
...note that 0x408552 is the return address on the stack just below the 0 that was pushed there by 0x408dc6.
Perhaps someone better versed in windows eccentricities can elaborate. Let me know if other info would be helpful. Also let me know if you have specific debugging you'd like me to do...