I'm currently trying to debug http://bugs.winehq.org/show_bug.cgi?id=25977.
Even when running "winedbg bin/release/loader.exe", this is what happens:
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00365327). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00365327 ESP:0033dd20 EBP:000003d9 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:00000000 ECX:0018e268 EDX:00000011 ESI:0018e268 EDI:0016e560 Stack dump: 0x0033dd20: 00000000 0018e268 003670f9 0033dd9c 0x0033dd30: 0033fb68 0002002a 001712b0 00000005 0x0033dd40: 100d2e46 00401920 0002002a 0033e39c 0x0033dd50: 0033ddc8 7edb2ff4 00000000 00000000 0x0033dd60: 00000000 00000000 00000690 0000041a 0x0033dd70: 0000002c 00000000 00000001 ffffffff 000c: sel=0067 base=00000000 limit=00000000 16-bit rw- Backtrace: 0x00365327: movl 0x0(%eax),%ecx Wine-dbg>bt Backtrace:
Any advice, or idea why this would happen? Furthermore, is it a bug with winedbg, and worth filing?
J. Leclanche
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 23.04.2011 um 11:34 schrieb Jerome Leclanche:
Any advice, or idea why this would happen?
For example the stack could be broken
Furthermore, is it a bug with winedbg, and worth filing?
If you think it is some problem with the debugger you may have more luck with gdb. On OSX this sometimes gives more helpful output. But I am afraid you'll need other debugging techniques like logfiles.
Le 23/04/2011 11:34, Jerome Leclanche a écrit :
I'm currently trying to debug http://bugs.winehq.org/show_bug.cgi?id=25977.
Even when running "winedbg bin/release/loader.exe", this is what happens:
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00365327). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00365327 ESP:0033dd20 EBP:000003d9 EFLAGS:00010246( R- -- I Z- -P- )
EBP has a "strange" value, so likely the current function has been compiled without frame pointer support (or has been screwed up) you need the debug info associated with that program to go further. do you have it ? or does the exec contain FPO information (winedump could be handy here)
"reading" the stack shows that calling function is at 0x3670f9 so disas 0x3670f9 might give you better info
A+