https://bugs.winehq.org/show_bug.cgi?id=52094
Bug ID: 52094 Summary: IDA Pro 7.6 crashes when loading idapython3.dll Product: Wine Version: 6.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: esteve.varela@gmail.com Distribution: ---
IDA Pro 7.6 (and 7.5) crash on startup when IDAPython3 is installed and configured.
Steps to reproduce: - Get an ida76sp1 installation - Install python3 using the exe installer (go to advanced, install for all users, and add to environment) - Run `wine idapyswitch.exe`, select the installation. - Run ida.exe, watch it crash and generate a crash dump.
This has been tested with Python 3.10.0, 3.9.9, and 3.8.10, all for the amd64 architecture. Python 3.4 couldn't be tested because the msi installer isn't working properly, and when ran unattended the proper DLL isn't installed.
Any ways to bypass this after IDAPython3 has been set up include removing the selected python3 install or removing idapython3.dll from the plugins folder. This gets IDA to run again, though IDAPython3 still won't work.
Crash dumps: https://files.catbox.moe/rsvacg.xz ("crashdumps.tar.xz") Nothing is shown in the command-line log that wouldn't be shown in a non-crashing run of the program.
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #1 from esteve.varela@gmail.com --- I forgot to note that IDAPython2 works just fine, provided idapyswitcher.exe hasn't been used.
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #2 from esteve.varela@gmail.com --- Managed to test python 3.4, by running the MSI unattended (wine msiexec /i python-3.4.4.amd64.msi ALLUSERS=1 /q), copying C:\Python34\DLLs\python3.dll and C:\windows\system32\python34.dll into C:\Python34, and using "wine idapyswitch --force-path 'C:\Python34\python34.dll'". This crashes too...
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #3 from esteve.varela@gmail.com --- As a side-note about the workarounds mentioned in the IDA 7.5 page[1]: Running idapyswitch.exe under windows doesn't make any difference compared to running it under linux, the checksums of the files generated by the tool are identical. In fact, not running idapyswitch under wine means the HKEY_CURRENT_USER\Software\Hex-Rays\IDA\Python3TargetDLL registry key will never be set, which means IDAPython3 will never be loaded. Setting up PATH, PYTHONPATH and PYTHONHOME makes no difference in the crash. The crash dumps in the first message were generated without any of these suggested workarounds.
[1]: https://appdb.winehq.org/objectManager.php?sClass=version&iId=39636&...
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #4 from esteve.varela@gmail.com --- The OS reported on is Kali Linux 2021.3, based on Debian Testing (Bookworm), using the relevant official WineHQ repositories "deb https://dl.winehq.org/wine-builds/debian/ bookworm main".
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #5 from esteve.varela@gmail.com --- A workaround for this bug is described at: https://appdb.winehq.org/objectManager.php?sClass=version&iId=40404&...
https://bugs.winehq.org/show_bug.cgi?id=52094
Jinoh Kang jinoh.kang.kr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr@gmail.com
--- Comment #6 from Jinoh Kang jinoh.kang.kr@gmail.com --- This bug has been around for quite some time.
An interesting part of this bug is that python3.dll works, but specific version DLLs such as python39.dll doesn't.
I think this bug has something to do with export forwarding.
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #7 from Jinoh Kang jinoh.kang.kr@gmail.com --- If my memory serves right, this is a regression.
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #8 from esteve.varela@gmail.com --- Yeah I'm aware this has been a bug ever since IDAPython3 released, and I'm not aware of a WINE version where this worked (IDAPython2 has always worked fine before). I just didn't bother reporting the bug for a while in hopes it'd sort itself with time. Only recently I decided to investigate. Using "wine idapyswitch.exe --force-path 'C:\Program Files\Python310\python3.dll'" doesn't seem to work either, but if you can give me more concrete instructions to force it to use python3.dll (as opposed to python310.dll), it might be useful to add onto AppDB. For now, letting IDA find the dll in $PATH seems to be the only solution...
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #9 from Jinoh Kang jinoh.kang.kr@gmail.com --- I have successfully traced the root cause of the bug--indeed it's the forwarded exports.
Wine does not always increment the refcount of the referee of a forwarded export when such an entry is resolved.
However I think I ran into some peculiarities of Windows DLL loader. Anyone knowledgeable on this topic?
(Workaround: pin python3<XYZ>.dll so that it doesn't go away)
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #10 from Jinoh Kang jinoh.kang.kr@gmail.com --- Fix committed: https://source.winehq.org/patches/data/222017
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #11 from Jinoh Kang jinoh.kang.kr@gmail.com --- Patch submitted [v3]: https://source.winehq.org/patches/data/222019
Test failures appear unrelated to this change (regression from previous patches?).
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #12 from Jinoh Kang jinoh.kang.kr@gmail.com --- (In reply to esteve.varela from comment #8)
Using "wine idapyswitch.exe --force-path 'C:\Program Files\Python310\python3.dll'" doesn't seem to work either, but if you can give me more concrete instructions to force it to use python3.dll (as opposed to python310.dll), it might be useful to add onto AppDB.
idapyswitch.exe cannot be used for this purpose. You have to edit the registry manually.
REGEDIT4
[HKEY_CURRENT_USER\SOFTWARE\Hex-Rays\IDA] Python3TargetDLL="C:\Program Files\Python310\python3.dll"
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #13 from Jinoh Kang jinoh.kang.kr@gmail.com --- Here is the (hopefully) final version of the patch serie:
- https://source.winehq.org/patches/data/222059 - https://source.winehq.org/patches/data/222060
Can you retest with the above patches applied?
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #14 from Jinoh Kang jinoh.kang.kr@gmail.com --- Fix confirmed locally.
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #15 from esteve.varela@gmail.com --- I've confirmed it too, though it doesn't apply cleanly on 6.23, so I had to build from git.
I should also mention that I had to clear out forward4.c and forward4.spec to get it to build, as I would otherwise get this error:
gcc -m64 -c -o dlls/kernel32/tests/forward4.o ../dlls/kernel32/tests/forward4.c -Idlls/kernel32/tests -I../dlls/kernel32/tests \ -Iinclude -I../include -I../include/msvcrt -D__WINESRC__ -D_MSVCR_VER=0 -fPIC \ -fasynchronous-unwind-tables -D_WIN32 -fno-builtin -fshort-wchar -mabi=ms -Wall -pipe \ -fcf-protection=none -fno-stack-protector -fno-strict-aliasing -Wdeclaration-after-statement \ -Wempty-body -Wignored-qualifiers -Winit-self -Wno-packed-not-aligned -Wshift-overflow=2 \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-4 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 {standard input}: Assembler messages: {standard input}:6: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:9: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:10: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:22: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:26: Error: cannot represent relocation type BFD_RELOC_RVA
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #16 from Jinoh Kang jinoh.kang.kr@gmail.com --- (In reply to esteve.varela from comment #15)
I've confirmed it too, though it doesn't apply cleanly on 6.23, so I had to build from git.
Yes, we're in 7.0-rc1.
I should also mention that I had to clear out forward4.c and forward4.spec to get it to build, as I would otherwise get this error:
gcc -m64 -c -o dlls/kernel32/tests/forward4.o ../dlls/kernel32/tests/forward4.c -Idlls/kernel32/tests -I../dlls/kernel32/tests \ -Iinclude -I../include -I../include/msvcrt -D__WINESRC__ -D_MSVCR_VER=0 -fPIC \ -fasynchronous-unwind-tables -D_WIN32 -fno-builtin -fshort-wchar -mabi=ms -Wall -pipe \ -fcf-protection=none -fno-stack-protector -fno-strict-aliasing -Wdeclaration-after-statement \ -Wempty-body -Wignored-qualifiers -Winit-self -Wno-packed-not-aligned -Wshift-overflow=2 \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-4 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 {standard input}: Assembler messages: {standard input}:6: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:9: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:10: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:22: Error: cannot represent relocation type BFD_RELOC_RVA {standard input}:26: Error: cannot represent relocation type BFD_RELOC_RVA
It looks like it's trying to build a source file as a Unix library and not as a PE file, which means something went wrong. Can you copy-paste the `./configure` line you used to build Wine?
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #17 from esteve.varela@gmail.com --- ../configure --enable-win64 --without-mingw
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #18 from Jinoh Kang jinoh.kang.kr@gmail.com --- Thanks! Fixed build without MinGW [v7]:
- https://source.winehq.org/patches/data/222146 - https://source.winehq.org/patches/data/222147
https://bugs.winehq.org/show_bug.cgi?id=52094
br.e.n.n.a.ns.pen.certmp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |br.e.n.n.a.ns.pen.certmp@gm | |ail.com
--- Comment #19 from br.e.n.n.a.ns.pen.certmp@gmail.com --- Issue is still present in the latest WineHQ 7.0 packages, except now it crashes before a dump can be made.
https://bugs.winehq.org/show_bug.cgi?id=52094
br.e.n.n.a.ns.pen.certmp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|br.e.n.n.a.ns.pen.certmp@gm | |ail.com |
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #20 from Jinoh Kang jinoh.kang.kr@gmail.com --- (In reply to br.e.n.n.a.ns.pen.certmp from comment #19)
Issue is still present in the latest WineHQ 7.0 packages, except now it crashes before a dump can be made.
It's probably a DWARF issue, and unrelated to this particular bug. You can try one of the workarounds above.
https://bugs.winehq.org/show_bug.cgi?id=52094
Luigi Sciolla luigi.sciolla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luigi.sciolla@gmail.com
--- Comment #21 from Luigi Sciolla luigi.sciolla@gmail.com --- (In reply to Jinoh Kang from comment #18)
Thanks! Fixed build without MinGW [v7]:
Any news? Has this patch been merged?
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #22 from Jinoh Kang jinoh.kang.kr@gmail.com --- (In reply to Luigi Sciolla from comment #21)
(In reply to Jinoh Kang from comment #18)
Thanks! Fixed build without MinGW [v7]:
Any news? Has this patch been merged?
No. It's still around, though: https://source.winehq.org/patches/data/228536
https://bugs.winehq.org/show_bug.cgi?id=52094
YUAN RUI number201724@me.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |number201724@me.com
--- Comment #23 from YUAN RUI number201724@me.com --- I also created a PR to fix this issue.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4662
https://bugs.winehq.org/show_bug.cgi?id=52094
--- Comment #24 from Jinoh Kang jinoh.kang.kr@gmail.com --- I attached a reference graph in https://gitlab.winehq.org/wine/wine/-/merge_requests/364 explaining the issue.