http://bugs.winehq.org/show_bug.cgi?id=31090
Bug #: 31090 Summary: Wine overwrites dyld debug information Product: Wine Version: 1.5.7 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader AssignedTo: wine-bugs@winehq.org ReportedBy: per@morth.org Classification: Unclassified
I've been trying to get windbag --gdb working on OS X. There seem to be multiple issues, but a major one is that it can't load the debug headers needed to get information out of the debugged processes.
What happens is that dbghelp/macho_module tries to read memory from the symbol _dyld_all_image_infos in the target process. Turns out this symbol is always at the address 0x8fe340e0, at least on my machine.
Looking with vmmap on a running wine process, this address is in an unreadable mapping:
VM_ALLOCATE 82000000-8d9f0000 [185.9M] ---/rwx SM=NUL
which I traced to
void mmap_init(void) { ... if (base > user_space_limit) reserve_area( user_space_limit, base ); }
before this call the region points to /usr/lib/dyld: __DATA 8fe33000-8fe38000 [ 20K] rw-/rwx SM=COW /usr/lib/dyld
but after it is as above.
But I'm afraid I don't know how to fix it. I tried adding
wine_mmap_add_reserved_area( (void*)0x82000000, 0x8ff2c000 - 0x82000000 );
to loader/main.c but it didn't seem to help. So I'm writing this bug report, hoping someone else is able to fix it.
http://bugs.winehq.org/show_bug.cgi?id=31090
--- Comment #1 from Per Johansson per@morth.org 2012-06-30 17:31:35 CDT --- Hrm, not sure why it said the wrong address in that copy paste, I've been experimenting a bit... correct one should be
VM_ALLOCATE 82000000-8fe00000 [222.0M] ---/rwx SM=NUL
http://bugs.winehq.org/show_bug.cgi?id=31090
--- Comment #2 from Per Johansson per@morth.org 2012-06-30 17:34:45 CDT --- Alright, now I'm looking like a fool... it's past bedtime here if it's an excuse. Anyway the problem is there, even if I can't seem to find the right values right now. If someone is willing to try to reproduce I'd be grateful.
http://bugs.winehq.org/show_bug.cgi?id=31090
--- Comment #3 from Per Johansson per@morth.org 2012-06-30 17:42:39 CDT --- Created attachment 40812 --> http://bugs.winehq.org/attachment.cgi?id=40812 Debug info patch
http://bugs.winehq.org/show_bug.cgi?id=31090
--- Comment #4 from Per Johansson per@morth.org 2012-06-30 17:43:34 CDT --- You might need to use the attached patch to see the vmmap. That's where I saw it overlap the dyld one.
http://bugs.winehq.org/show_bug.cgi?id=31090
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #5 from Ken Thomases ken@codeweavers.com --- Please retest with Wine 1.7.8 or later. In particular, this patch http://source.winehq.org/git/wine.git/?a=commit;h=1577fb6c3f5941a9b2ba1fec7e38e61cdfa2b757 may have helped.
dbghelp/macho_module assumed that _dyld_all_image_infos was always at a fixed address for any given build of the OS. Basically, it looked up the symbol in the symbol table of /usr/lib/dyld and used that static address.
However, in recent versions of the OS, dyld is loaded at a random address for security (Address Space Layout Randomization). Therefore, dbghelp/macho_module was looking in the wrong place.
I suspect that Wine was not re-allocating the memory occupied by dyld. It's just that you were misled to look at the wrong memory range by the invalid assumption embedded in dbghelp.
https://bugs.winehq.org/show_bug.cgi?id=31090
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |ABANDONED
--- Comment #6 from Austin English austinenglish@gmail.com --- Abandoned, potentially fixed.
https://bugs.winehq.org/show_bug.cgi?id=31090
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Austin English austinenglish@gmail.com --- Closing.