http://bugs.winehq.org/show_bug.cgi?id=24676
Summary: winedbg causes Unhandled page fault on read access during stepi Product: Wine Version: 1.3.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winedbg AssignedTo: wine-bugs@winehq.org ReportedBy: andrew.pub@sophistasis.com
Created an attachment (id=31191) --> (http://bugs.winehq.org/attachment.cgi?id=31191) A step by step show of how the error is gotten w/ edited terminal output session
During a debug of a set of 3rd party DLL's combined with a program, calls to memory pages which need to be ?swapped in? will cause an Unhandled page fault when stepi is used, *but* will run properly if that code segment is executed seamlessly. Essentially, the debugger is interfering with the page swapping algorithms intermittently making debugging nearly impossible.
The test program is ebook_msc.exe found here:
http://projects.mobileread.com/reader/users/porkupan/PRS900/flash%20packages...
In the attachment, a short step by step view of how to re-create the bug is given including my comments (!)
The backtrace often shows the error point in ntdll.
http://bugs.winehq.org/show_bug.cgi?id=24676
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://projects.mobileread. | |com/reader/users/porkupan/P | |RS900/flash%20packages/PRS9 | |00.Flash.Package.1.02e.zip
http://bugs.winehq.org/show_bug.cgi?id=24676
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #1 from Eric Pouech eric.pouech@orange.fr 2010-10-09 03:38:46 CDT --- I can't reproduce what you describe. Wine-dbg>break mscenccomm!MSC_USBConnect fixme:dbghelp_dwarf:compute_location Only supporting one breg (18 -> 24) Many symbols with name 'mscenccomm!MSC_USBConnect', choose the one you want (<cr> to abort): [1]: 0x100011e0 MSC_USBConnect in mscenccomm [2]: 0x100011e0 MSC_USBConnect in mscenccomm => 1 Breakpoint 1 at 0x100011e0 MSC_USBConnect in mscenccomm Wine-dbg>c Stopped on breakpoint 1 at 0x100011e0 MSC_USBConnect in mscenccomm Wine-dbg>stepi 17 0x10001a3f: call *%esi Wine-dbg>nexti 10 0x10001a5d: movl %eax,%ebp
which works flawlessly afterwards. Are you sure you haven't set other breakpoints (on addresses which are not instructions boundaries? => this could explain why you get different instructions at the end) btw, try also hardware breakpoints, they don't have the defaults of modifying instructions code.
http://bugs.winehq.org/show_bug.cgi?id=24676
--- Comment #2 from Andrew andrew.pub@sophistasis.com 2010-10-09 16:05:04 CDT --- (In reply to comment #1)
I can't reproduce what you describe. Wine-dbg>break mscenccomm!MSC_USBConnect fixme:dbghelp_dwarf:compute_location Only supporting one breg (18 -> 24) Many symbols with name 'mscenccomm!MSC_USBConnect', choose the one you want (<cr> to abort): [1]: 0x100011e0 MSC_USBConnect in mscenccomm [2]: 0x100011e0 MSC_USBConnect in mscenccomm => 1 Breakpoint 1 at 0x100011e0 MSC_USBConnect in mscenccomm Wine-dbg>c Stopped on breakpoint 1 at 0x100011e0 MSC_USBConnect in mscenccomm Wine-dbg>stepi 17 0x10001a3f: call *%esi Wine-dbg>nexti 10 0x10001a5d: movl %eax,%ebp
which works flawlessly afterwards. Are you sure you haven't set other breakpoints (on addresses which are not instructions boundaries? => this could explain why you get different instructions at the end) btw, try also hardware breakpoints, they don't have the defaults of modifying instructions code.
No, there are no other breakpoints. I just tested it using the --gdb setting, and it works fine as a remote interface (no bug)... (though a separate bug popped up, which I wont go into for it isn't repeatable/complete)
Oddly, your dis-assembly stopped at 0x10001a5d -- whereas mine stops at 0x10001a5e for the exact same command sequence using pure winedbg without --gdb.
so,... I just backed up -- and re deleted my wine registry (.wine) and made it rebuild all defaults (again) to see what would happen from scratch, and now I get the same dis-assembly as you which is not a call instruction using pure wine-dbg. Hmm... That suggests that adding a USB drive name to the registry causes wine-dbg to disassemble instructions differently than gdb. I'll post again when I have isolated the cause(s) required to crash the debugger.
http://bugs.winehq.org/show_bug.cgi?id=24676
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #3 from Eric Pouech eric.pouech@orange.fr 2010-10-10 02:27:04 CDT ---
That suggests that adding a USB drive name to the registry causes wine-dbg to disassemble instructions differently than gdb. I'll post again when I have isolated the cause(s) required to crash the debugger.
That's complete non sense. The program image has been modified somehow. Either on disk, or by poking directly in its address space (for example, by setting breakpoints) Marking bug as invalid. A+
http://bugs.winehq.org/show_bug.cgi?id=24676
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2010-10-10 11:40:57 CDT --- Closing invalid.
-
wine-bugs＠winehq.org