https://bugs.winehq.org/show_bug.cgi?id=43418
Bug ID: 43418 Summary: gOddysey Pacemaker crashes with "User lib not found" Product: Wine Version: 2.12 Hardware: x86 URL: http://web.archive.org/web/20110624013029if_/http://we bzoom.webs.com/smiff/PaceMakerR.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dark.shadow4@web.de Distribution: ---
Split of from Bug 43414. For me the program doesn't work at all, while the OP from Bug 43414 reported it working.
Snipped from the log that looks suspicous to me: ------ 009:Ret PE DLL (proc=0x63cc6560,module=0x63c60000 L"msvcrt.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0009:Call PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_ATTACH,res=(nil)) trace:seh:raise_exception code=c0000005 flags=0 addr=0x22c6010 ip=022c6010 tid=0009 trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=9eeef1ec trace:seh:raise_exception eax=02251000 ebx=7bd06000 ecx=b68a9cb0 edx=0033f95c esi=0033f5d8 edi=00000001 trace:seh:raise_exception ebp=0033f5b8 esp=0033f59c cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7bcc7010 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x7bca52f0 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x7bca52f0 returned 1 0009:exception in PE entry point (proc=0x2251000,module=0x2250000,reason=PROCESS_ATTACH,res=(nil)) 0009:Ret PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_ATTACH,res=(nil)) retval=0 0009:Call PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_DETACH,res=(nil)) trace:seh:raise_exception code=c0000005 flags=0 addr=0x22510a0 ip=022510a0 tid=0009 trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=9eedf000 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=02250000 edx=0033f900 esi=00000001 edi=00000000 trace:seh:raise_exception ebp=0033f5b8 esp=0033f5a0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7bcc7010 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x7bca52f0 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x7bca52f0 returned 1 0009:exception in PE entry point (proc=0x2251000,module=0x2250000,reason=PROCESS_DETACH,res=(nil)) 0009:Ret PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_DETACH,res=(nil)) retval=0 0009:Ret KERNEL32.LoadLibraryA() retval=00000000 ret=100092fe 0009:Call KERNEL32.LoadLibraryA(0067fb94 "blitzclose.dll") ret=100092fe 0009:Call PE DLL (proc=0x2251199,module=0x2250000 L"blitzclose.dll",reason=PROCESS_ATTACH,res=(nil)) ------
It seems like it can't load the DLLs, and thus crashes. But I might be wrong.
https://bugs.winehq.org/show_bug.cgi?id=43418
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Created attachment 58776 --> https://bugs.winehq.org/attachment.cgi?id=58776 Log with +relay,+seh
Log was to big to attach, add it compressed.
https://bugs.winehq.org/show_bug.cgi?id=43418
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- It happens due to a crash at ------ <jv-ode.malloc> jmp dword ptr ds:[610D0E14] ------ Any idea how that is supposed to work? There's supposed to be a malloc function, but there is just unaccessible memory, so the jump results in a SEGFAULT. It looks very much like the Import Address Table, but no idea why none of the jumps would work.
https://bugs.winehq.org/show_bug.cgi?id=43418
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords| |download
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Still relevant as of wine-4.0-rc6.
https://bugs.winehq.org/show_bug.cgi?id=43418
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Anastasius Focht focht@gmx.net --- Hello Fabian,
the app works for me too.
Just a guess: there might be something broken wrt relocation processing.
'jv-ode.dll' optional header:
--- snip --- Magic: 0x010B (HDR32_MAGIC) MajorLinkerVersion: 0x02 MinorLinkerVersion: 0x38 -> 2.56 SizeOfCode: 0x0007BA00 SizeOfInitializedData: 0x00089800 SizeOfUninitializedData: 0x00006800 AddressOfEntryPoint: 0x00001000 BaseOfCode: 0x00001000 BaseOfData: 0x0007D000 ImageBase: 0x65640000 SectionAlignment: 0x00001000 FileAlignment: 0x00000200 MajorOperatingSystemVersion: 0x0004 MinorOperatingSystemVersion: 0x0000 -> 4.00 MajorImageVersion: 0x0001 MinorImageVersion: 0x0000 -> 1.00 MajorSubsystemVersion: 0x0004 MinorSubsystemVersion: 0x0000 -> 4.00 Win32VersionValue: 0x00000000 SizeOfImage: 0x00096000 SizeOfHeaders: 0x00000400 CheckSum: 0x000BBEFF Subsystem: 0x0003 (WINDOWS_CUI) DllCharacteristics: 0x0000 SizeOfStackReserve: 0x00200000 SizeOfStackCommit: 0x00001000 SizeOfHeapReserve: 0x00100000 SizeOfHeapCommit: 0x00001000 LoaderFlags: 0x00000000 NumberOfRvaAndSizes: 0x00000010
DataDirectory (16) RVA Size ------------- ---------- ---------- ExportTable 0x00086000 0x00008168 (".edata") ImportTable 0x0008F000 0x000005C0 (".idata") Resource 0x00090000 0x00000378 (".rsrc") Exception 0x00000000 0x00000000 Security 0x00000000 0x00000000 Relocation 0x00091000 0x00004098 (".reloc") Debug 0x00000000 0x00000000 Copyright 0x00000000 0x00000000 GlobalPtr 0x00000000 0x00000000 TLSTable 0x00000000 0x00000000 LoadConfig 0x00000000 0x00000000 BoundImport 0x00000000 0x00000000 IAT 0x00000000 0x00000000 DelayImport 0x00000000 0x00000000 COM 0x00000000 0x00000000 Reserved 0x00000000 0x00000000 --- snip ---
Preferred image load base: 0x65640000 According to your trace log: 0x2251000 which means the dll got relocated.
Could you attach a new trace log with:
--- snip --- $ WINEDEBUG=+seh,+relay,+module,+loaddll,+imports ... --- snip ---
$ sha1sum PaceMakerR.zip 819d770763c00c9c4bc4d6e12cca0f89a7b202b8 PaceMakerR.zip
$ du -sh PaceMakerR.zip 1.8M PaceMakerR.zip
$ wine --version wine-4.0-rc6
Regards
https://bugs.winehq.org/show_bug.cgi?id=43418
--- Comment #5 from Fabian Maurer dark.shadow4@web.de --- Created attachment 63270 --> https://bugs.winehq.org/attachment.cgi?id=63270 Log with WINEDEBUG=+seh,+relay,+module,+loaddll,+imports
Thanks for the insight, no idea what might be different on my system though. New log attached.
https://bugs.winehq.org/show_bug.cgi?id=43418
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Still present as of wine-7.20. And still no idea why it's different for me. Does the app still work for you?
https://bugs.winehq.org/show_bug.cgi?id=43418
--- Comment #7 from Fabian Maurer dark.shadow4@web.de --- Still present as of wine-8.20
https://bugs.winehq.org/show_bug.cgi?id=43418
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- Created attachment 75588 --> https://bugs.winehq.org/attachment.cgi?id=75588 Test program
Definitely related to relocation. If in the function "LoadLibraryA" you add the line
VirtualAlloc((void*)0x65640000, 1, MEM_RESERVE, PAGE_READWRITE);
as first statement, you should be able to reproduce the issue.
Problematic jmp is at (new module base) + 0x76010 - jump address is at 0x76012 Usually
jmp *0x656cf1ec
For the new base 0x4230000 it gets relocated (IMAGE_REL_BASED_HIGHLOW) with delta 0x9ebf0000 into
jmp *0x42bf1ec
which looks correct. But then it gets relocated again (IMAGE_REL_BASED_HIGHLOW) with delta 0x9ebf0000 into
jmp *0xa2eaf1ec
Attaching a simple test program to test a relocation failure.
Without VirtualAlloc we get
mod is 65640000 jmp offset to base: 8f1ec
With VirtualAlloc we get
error 998 (ERROR_NOACCESS) on XP, Win7 or 1114 (ERROR_DLL_INIT_FAILED) on Win10
I think the DLL just has broken relocations and there actually is no Wine bug here.
https://bugs.winehq.org/show_bug.cgi?id=43418
--- Comment #9 from Fabian Maurer dark.shadow4@web.de --- FWIW, on my system the address 0x65640000 is occupied by "/memfd:pulseaudio (deleted)" (0x61a00000 - 0x65a00000)
Maybe Wine could try harder to give DLLs their preferred address? Not sure how exactly though.
https://bugs.winehq.org/show_bug.cgi?id=43418
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- You could try with new wow64 mode, which should make it more likely that the address would remain free. But I agree, the dll is broken, it contains duplicate relocations.