[Bug 54250] New: winedbg loads wrong debug symbols for builtin dlls
https://bugs.winehq.org/show_bug.cgi?id=54250 Bug ID: 54250 Summary: winedbg loads wrong debug symbols for builtin dlls Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winedbg Assignee: wine-bugs(a)winehq.org Reporter: ake.rehnman(a)gmail.com Distribution: --- Created attachment 73804 --> https://bugs.winehq.org/attachment.cgi?id=73804 Patched winedbg attempt Winedbg loads the wrong debugging info for dlls where a native dll exists in the prefix and the native dll is replaced with the built-in version. For instance the lpImageName in the DEBUG_EVENT struct contains the path to the C:\Windows\System32\somedll.dll but it is replaced with the built-in version from the build directory (in my case) that is actually mapped in to memory. So in this case winedbg loads the debug symbols from from the system directory and not the one that is in the build directory. However it looks like if calling NtQueryInformationFile with the file handle we get the correct name to the loaded dll. See the attached patch how I solved the issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Assignee|wine-bugs(a)winehq.org |eric.pouech(a)gmail.com Status|UNCONFIRMED |ASSIGNED CC| |eric.pouech(a)gmail.com --- Comment #1 from Eric Pouech <eric.pouech(a)gmail.com> --- Created attachment 73816 --> https://bugs.winehq.org/attachment.cgi?id=73816 alternative patch Hi, thanks for the feedback. Yes sometimes winedbg (in fact dbghelp DLL) have slightly different image lookup implementation. Does the attached patch work? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #2 from ake.rehnman(a)gmail.com --- Hi, unfortunately the alternative patch does not work. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #3 from ake.rehnman(a)gmail.com --- It does seem it is loading the correct symbol table with the alternate patch but it is still wrong somehow... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #4 from Eric Pouech <eric.pouech(a)gmail.com> --- I'm not sure to get fully your situation: what I understand is: - you use wine from the build tree (compilation by yourself, wine not installed) - you run wine from the build tree - in that case the system dlls from c:\windows\system in the prefix are copied from the build tree, so it shouldn't change using one or the other would you mind describing: - how things are invoked (if different from above) - what let you think you get the wrong debug info? TIA -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #5 from ake.rehnman(a)gmail.com --- (In reply to Eric Pouech from comment #4)
I'm not sure to get fully your situation: what I understand is: - you use wine from the build tree (compilation by yourself, wine not installed) - you run wine from the build tree - in that case the system dlls from c:\windows\system in the prefix are copied from the build tree, so it shouldn't change using one or the other
would you mind describing: - how things are invoked (if different from above) - what let you think you get the wrong debug info?
TIA
It is correct, I am running from the build tree. How ever if there is a *native* windows dll in the prefix it is by default overridden by the builtin version in the build tree. But when winedbg tries to load the symbol table for the builtin dll it was loading the debug symbols (or at least the exports) from the native windows dll. With the "alternate patch" it looks like it is loading the debug symbols from the dll in the build tree. But the debug symbols still points to the wrong addresses. I am going to dig a little more to see where it goes wrong... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #6 from Eric Pouech <eric.pouech(a)gmail.com> --- 1) I assume you're using WINEDLLOVERRIDES to force loading of native (in prefix) instead of wine's builtin (in tree) 2) can you post the WINEDEBUG=+dbghelp trace -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #7 from ake.rehnman(a)gmail.com --- (In reply to Eric Pouech from comment #6)
1) I assume you're using WINEDLLOVERRIDES to force loading of native (in prefix) instead of wine's builtin (in tree)
Actually it is the other way around. There are a number of native dlls in the System32 directory but those are replaced with the built-in in my build tree.
2) can you post the WINEDEBUG=+dbghelp trace
Good news! Wine-dbg actually loads the correct symbols with the alternate patch. So this is working. BUT I am usually running Winedbg as a gdb-server and THEN the symols gets screwed up. So when I use Wine-dbg interactively I can set breakpoints on the functions in the built-in dlls and everything works. But when I switch to gdb and run Wine-dbg as gdbserver I get the symbols for the NATIVE dlls. Weird... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #8 from ake.rehnman(a)gmail.com --- Created attachment 73823 --> https://bugs.winehq.org/attachment.cgi?id=73823 alternative patch 2 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #9 from ake.rehnman(a)gmail.com --- gdb also needs the path to built-in ddls -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #10 from Eric Pouech <eric.pouech(a)gmail.com> --- hi your addition looks correct since Wine's currently is in code freeze (only bug fixes allowed), I'm a bit worried by the changes: at least the one I proposed <g>. As it changes the code path for every PE loaded, it may uncover some other bugs. (Like not updating LoadedImageName accordingly). Even if its the right thing to do (using the hFile from the load DLL debug event, hence passed by the system), I'm a bit reluctant to create a merge request from it. Question: I wonder if your change alone (without passing hFile) produces the same right effects (at least on gdb-proxy mode)? A+ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #11 from ake.rehnman(a)gmail.com --- (In reply to Eric Pouech from comment #10)
Question: I wonder if your change alone (without passing hFile) produces the same right effects (at least on gdb-proxy mode)?
It does not work without hFile, not in wine-dbg nor gdb. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73816|0 |1 is obsolete| | --- Comment #12 from Eric Pouech <eric.pouech(a)gmail.com> --- Created attachment 73827 --> https://bugs.winehq.org/attachment.cgi?id=73827 proposed patch thinking a bit more about the fix, there are still a couple of things to iron out: - the first issue stems from the load dll debug event passing the filename as c:\windows\system while hFile is opened on the overridden DLL in the build tree - this is done to hide from regular applications the wine internal redirections (like buildtree) - so we shouldn't expose that redirected filename to regular app (so I changed the patch to only retrieve the redirected path when some wine extensions are enabled instead of always exposing the redirected filename) - also, if we have a valid hFile from the DLL load event, we shouldn't look for redirection (especially since it's passed by the system, hence ensuring that it's opened on the loaded module...). so I changed the patch to get the redirected filename from the file handle (inserting back your first patch, yet modified) so the attached patch should be cleaner IMO -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #13 from ake.rehnman(a)gmail.com --- Something is broken with the "proposed patch" ... (gdb) target remote localhost:38453 Remote debugging using localhost:38453 warning: remote target does not support file transfer, attempting to access files from local filesystem. Reading symbols from /home/are/project/xwinetest/rectangle.exe... warning: while parsing target library list: not well-formed (invalid token) 0x000000017006d755 in ?? () -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73827|0 |1 is obsolete| | --- Comment #14 from Eric Pouech <eric.pouech(a)gmail.com> --- Created attachment 73829 --> https://bugs.winehq.org/attachment.cgi?id=73829 proposed patch silly me and last minute change <g> should be better by now ;-) thanks for baring with me -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #15 from ake.rehnman(a)gmail.com --- Something is not right. The path we get from NtQueryInformationFile does not contain the prefix or drive for things in the C:\Windows\System32 dir... Ex 0020:0024:fixme:dbghelp:pe_load_native_module LoadedImageName=L"C:\\windows\\system32\\USP10.dll" name=L"C:\\windows\\system32\\USP10.dll" real_path=L"\\Windows\\System32\\usp10.dll" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #73829|0 |1 is obsolete| | --- Comment #16 from Eric Pouech <eric.pouech(a)gmail.com> --- Created attachment 73835 --> https://bugs.winehq.org/attachment.cgi?id=73835 proposed patch another try <g> I also splitted the patch in pieces for creating the merge request. Let me know if: - your name is correct - you agree for submission for your derived code -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #17 from ake.rehnman(a)gmail.com --- (In reply to Eric Pouech from comment #16)
Created attachment 73835 [details] proposed patch
another try <g>
Seem to work :-) I don't think the stripping of the nt object prefix "\\??\\" is necessary. I tried without it and it works. wine_get_unix_file_name() strips it anyways.
I also splitted the patch in pieces for creating the merge request. Let me know if: - your name is correct
YES
- you agree for submission for your derived code
AGREE -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #18 from Eric Pouech <eric.pouech(a)gmail.com> --- (In reply to ake.rehnman from comment #17)
(In reply to Eric Pouech from comment #16)
Created attachment 73835 [details] proposed patch
another try <g>
Seem to work :-) at least <g>! I don't think the stripping of the nt object prefix "\\??\\" is necessary. I tried without it and it works. wine_get_unix_file_name() strips it anyways. agreed
I also splitted the patch in pieces for creating the merge request. Let me know if: - your name is correct
YES
- you agree for submission for your derived code
AGREE
merge request posted: https://gitlab.winehq.org/wine/wine/-/merge_requests/1913 thanks for your time & support -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #19 from Eric Pouech <eric.pouech(a)gmail.com> --- proposed fixed committed as 168c7a475d43cb7688636f0eb13b3892322333c0 and 3 following commits for inclusion in wine 8.1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 temp82(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ake.rehnman(a)gmail.com, | |temp82(a)luukku.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani(a)winehq.org --- Comment #20 from Michael Stefaniuc <mstefani(a)winehq.org> --- Is this bug fixed? I see https://gitlab.winehq.org/wine/wine/-/merge_requests/1913 was merged. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 --- Comment #21 from Eric Pouech <eric.pouech(a)gmail.com> --- (In reply to Michael Stefaniuc from comment #20)
Is this bug fixed? I see https://gitlab.winehq.org/wine/wine/-/merge_requests/1913 was merged.
In regular process; it's up to the reported to acknowledge the bug has been fixed. Here, Ake tested it before the merge & confirmed it worked. So unsure if process can be twisted that way. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 ake.rehnman(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED --- Comment #22 from ake.rehnman(a)gmail.com --- Fixed with https://gitlab.winehq.org/wine/wine/-/merge_requests/1913 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a89975f731b5cfe822bd7f8d33d | |a0a9481b1c151 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54250 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #23 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 8.8. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla