https://bugs.winehq.org/show_bug.cgi?id=44492
Bug ID: 44492 Summary: winedbg reports unknown mode, fails to backtrace etc. in protected-mode Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: z.figura12@gmail.com Distribution: ---
While trying to debug bug #42554 I found that winedbg persistently refused to give backtraces, both in the crash dialog and when started via `wine winedbg MSBSOLAR.EXE`. The following output is given:
------ Unhandled exception: page fault on read access to 0x00004540 bad address. In (null) mode. Register dump: CS:12af SS:11d7 DS:12c7 ES:1237 FS:0063 GS:006bBad segment (4567) Stack dump: 000c: sel=0067 base=00000000 limit=00000000 32-bit rw- Backtrace: =>0 Unknown mode ffffffff (Unknown mode ffffffff ) Unknown mode ffffffff: -- no code accessible -- ------
Tracing this back to its source, I find that ptrace seems to be returning incorrect output:
0039: get_selector_entry( handle=002c, entry=597 ) 0030: *signal* signal=19 0039: get_selector_entry() = 0 { base=00000000, limit=00000000, flags=52 }
Obviously the base should not be NULL, nor the limit 0, and the flags should be 9b (WINE_LDT_FLAGS_ALLOCATED|WINE_LDT_FLAGS_CODE). If I add traces to libs/wine/ldt.c, nothing is modifying the entry past the point at which it is set, so it seems like the fault lies in ptrace... an audacious claim to be sure.
I'm almost sure this used to work correctly, but I can't figure out when. I checked wine-2.10 and 3.0, and it was still broken then. I also checked on Arch (well, Manjaro) just in case this was another Ubuntu-related ptrace breakage, but it shows the same behaviour there.
https://bugs.winehq.org/show_bug.cgi?id=44492
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |3.1 Hardware|x86 |x86-64 Component|-unknown |wineserver
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- I figured out the difference—it's broken on 64-bit. I simultaneously figured out why ;-)
https://bugs.winehq.org/show_bug.cgi?id=44492
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|winedbg reports unknown |winedbg reports unknown |mode, fails to backtrace |mode, fails to backtrace |etc. in protected-mode |etc. in protected-mode with | |64-bit wineserver
https://bugs.winehq.org/show_bug.cgi?id=44492
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |c6dfce272309c1ad869886a0fce | |186c795f3e5b7 Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- Fixed by c6dfce272309c1ad869886a0fce186c795f3e5b7.
https://bugs.winehq.org/show_bug.cgi?id=44492
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.2.
https://bugs.winehq.org/show_bug.cgi?id=44492
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.0.x
https://bugs.winehq.org/show_bug.cgi?id=44492
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.0.x |---
--- Comment #4 from Michael Stefaniuc mstefani@winehq.org --- Removing the 3.0.x milestone from bugs included in 3.0.1.