https://bugs.winehq.org/show_bug.cgi?id=55993
Bug ID: 55993 Summary: PLSQL Developer: Hangs when trying to connect a database. Product: Wine Version: 8.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: bernhardu@mailbox.org Distribution: ---
Trying to connect to a database like described in the now fixed bug #55833, shows an application hang:
0110:err:sync:RtlpWaitForCriticalSection section 00006FFFF8573D68 "?" wait timed out in thread 0110, blocked by 0000, retrying (60 sec)
This seems to be another regression:
efd03f40e6e315d89cd1d09c48180aae82033f9f is the first broken commit commit efd03f40e6e315d89cd1d09c48180aae82033f9f Author: Alexandre Julliard julliard@winehq.org Date: Thu Oct 5 10:41:47 2023 +0200 server: Assign a system-wide mapping address for dynamic base modules.
Reverting this efd03f40 (and ec3de128) makes PLSQL not to hang.
There is another regression bug 55967 pointing to the same commit.
https://bugs.winehq.org/show_bug.cgi?id=55993
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |efd03f40e6e315d89cd1d09c481 | |80aae82033f9f Keywords| |download, regression
https://bugs.winehq.org/show_bug.cgi?id=55993
--- Comment #1 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 75606 --> https://bugs.winehq.org/attachment.cgi?id=75606 Minimal revert of efd03f40 to make PLSQL Developer not hang.
https://bugs.winehq.org/show_bug.cgi?id=55993
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- Can you please explain how to reproduce this?
https://bugs.winehq.org/show_bug.cgi?id=55993
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 75618 --> https://bugs.winehq.org/attachment.cgi?id=75618 reproduce.txt
(In reply to Alexandre Julliard from comment #2)
Can you please explain how to reproduce this?
This file contains the steps to reproduce this issue.
https://bugs.winehq.org/show_bug.cgi?id=55993
--- Comment #4 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 75620 --> https://bugs.winehq.org/attachment.cgi?id=75620 Add logging for related functions.
(In reply to Alexandre Julliard from comment #2)
I tried to get some more information and found an exception happens, after the press to the OK button:
WINEDEBUG=+seh: 012c:trace:seh:signal (22, 00006FFFEB73D530) 012c:trace:seh:dispatch_exception code=c0000005 flags=0 addr=0000700000000008 ip=700000000008 012c:trace:seh:dispatch_exception info[0]=0000000000000000 012c:trace:seh:dispatch_exception info[1]=00007000000439d4 012c:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised
This instructions are reached because plsqldev.exe does short before: => 0x00000000006b8afc: call *0x38a7fc6(%rip) # 0x3f60ac8
This memory 0x3f60ac8 seems to be written here: 0x00000000006b8bb4: lea 0x21(%rip),%rdx # 0x6b8bdc 0x00000000006b8bbb: call 0x42d580 0x00000000006b8bc0: mov %rax,%rcx 0x00000000006b8bc3: lea -0x2da(%rip),%rdx # 0x6b88f0 0x00000000006b8bca: call 0x481420 0x00000000006b8bcf: mov %rax,0x38a7ef2(%rip) # 0x3f60ac8 0x00000000006b8bd6: lea 0x20(%rbp),%rsp 0x00000000006b8bda: pop %rbp 0x00000000006b8bdb: ret (gdb) x/hs 0x6b8bdc 0x6b8bdc: u"CreateFileA"
Therefore it looks to me like plsqldev.exe takes the address of CreateFileA and does some crazy things with this address like VirtualQuery, VirtualProtect and VirtualAlloc. Which leads finally in kind of storing a trampoline behind kernel32.dll for CreateFileA.
Before the regression GetProcAddr returns for CreateFileA e.g. 0x17800C464. With the trampoline at 0x1781c0000.
After the regression GetProcAddr returns for CreateFileA 00006FFFFFAAC464. And plsqldev.exe iterates from 0x6FFFFFAE0000 upwards and finally VirtualAlloc succeeds at 0x700000000000.
Failing: => 0x0000700000000000: lea 0x0(%rsp),%rsp 0x0000700000000008: jmp *0x439c6(%rip) # 0x7000000439d4 0x000070000000000e: jmp *0x0(%rip) # 0x700000000014 (gdb) x/1xg 0x7000000439d4 0x7000000439d4: Cannot access memory at address 0x7000000439d4
Working: => 0x00000001781c0000: lea 0x0(%rsp),%rsp 0x00000001781c0008: jmp *-0x1701d6(%rip) # 0x17804fe38 0x00000001781c000e: jmp *0x0(%rip) # 0x1781c0014 (gdb) x/1xg 0x17804fe38 0x17804fe38: 0x00006fffff499640
So it looks like the generated trampoline is faulty?
Attached file adds some logging and workaround to not respect wineservers requested address for kernel32.
https://bugs.winehq.org/show_bug.cgi?id=55993
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #5 from Fabian Maurer dark.shadow4@web.de --- is this fixed by https://gitlab.winehq.org/wine/wine/-/commit/d96864eb4fbdbd384094b2c7754fc45... ?
https://bugs.winehq.org/show_bug.cgi?id=55993
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d96864eb4fbdbd384094b2c7754 | |fc45a3a41d708 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #6 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to Fabian Maurer from comment #5)
is this fixed by https://gitlab.winehq.org/wine/wine/-/commit/ d96864eb4fbdbd384094b2c7754fc45a3a41d708 ?
Thanks for the note. I can confirm this solves the hang.
While debugging I found such trampolines get created 4 times, for CreateFileA, CreateThread, ExitThread and RaiseException.
With this commit now the first, second and fourth have now negative offsets in the jump instruction. The third looks different without such jump offset.
What makes me wonder is the fourth is now still above 0x700000000000, but looks good now with a negative jump offset.
https://bugs.winehq.org/show_bug.cgi?id=55993
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.0-rc2.