http://bugs.winehq.org/show_bug.cgi?id=58203
Bug ID: 58203 Summary: PL/SQL Developer: All system memory gets eaten Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: robertdejager@tutanota.com Distribution: ---
Created attachment 78505 --> http://bugs.winehq.org/attachment.cgi?id=78505 Oracle Instant Client registry entries
Since Wine version 10.6, PL/SQL Developer uses up all system memory. The system freezes up for a bit until memory management kicks in.
In PL/SQL Developer version 15, no UI is shown. PL/SQL Developer 16 does draw UI, but eats memory all the same.
Steps to reproduce: * Install wine 10.6 or 10.7 * Download Oracle Instant Client (64 bit) and unzip into your prefix in c:\ORACLE\instantclient_23.7 (not entirely sure if this is needed to reproduce the bug) * https://download.oracle.com/otn_software/nt/instantclient/2370000/instantcli... * Import the registry entries from the attached .reg file * Edit c:\ORACLE\instantclient_23.7\tnsnames.ora and add a connect string for a database (apologies, I cannot provide a database or a connect string for it) (not entirely sure if this is needed to reproduce the bug) * Install PL/SQL Developer 15 (64 bit) or PL/SQL Developer 16 (64 bit) * https://www.allroundautomations.com/files/trial/plsqldev1504x64.msi * https://www.allroundautomations.com/files/trial/plsqldev1604x64.msi * Run PL/SQL Developer
Workaround: * Downgrade to wine <= 10.5
http://bugs.winehq.org/show_bug.cgi?id=58203
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org Regression SHA1| |510ad5578a487c4d3e35a330bd5 | |d92cfeabeebc7 Keywords| |download, regression
--- Comment #1 from Bernhard Übelacker bernhardu@mailbox.org --- Creating a tnsnames.ora seems not neccessary.
A git bisect points here: commit 510ad5578a487c4d3e35a330bd5d92cfeabeebc7 Author: Esme Povirk esme@codeweavers.com Date: Sat Apr 6 21:18:54 2024 +0000
gdiplus: Implement path to region conversion without gdi32.
This will later allow for optimization by limiting the area we consider to the region's bounding rectangle.
dlls/gdiplus/region.c | 253 +++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 210 insertions(+), 43 deletions(-)
Reverting all recent commits to region.c makes current git work again: git show eca84ca2 | git apply -R git show 0673a77a | git apply -R git show f82a8eef | git apply -R git show e557db75 | git apply -R git show 510ad557 | git apply -R
Re-adding 510ad557 alone makes the memory consumption visible again: git show 510ad557 | git apply
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #2 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 78511 --> http://bugs.winehq.org/attachment.cgi?id=78511 plsql-partial-backtrace.txt
This partial backtrace I could retrieve from the first thread of a plsqldev.exe when it started to collect memory, and shows functions from gdiplus. (Unfortunately winedbg let me not step further.)
http://bugs.winehq.org/show_bug.cgi?id=58203
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |gdiplus
http://bugs.winehq.org/show_bug.cgi?id=58203
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 78519 --> http://bugs.winehq.org/attachment.cgi?id=78519 plsql-more-details_stdout_msys-gdb-backtrace_workaround_trace+gdiplus.txt
This attachments contains some more details: - plain stdout of starting plsqldev.exe - backtrace from an msys2 gdb - a hack to leave flatten_bezier in case there are more than 10000 elements added - last lines of a +gdiplus trace
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #4 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 78520 --> http://bugs.winehq.org/attachment.cgi?id=78520 plsql-logging-shows-NaN_better-workaround.txt
This attachement adds some logging to the input data of flatten_bezier, and shows start and endpont coordinates are "-nan(ind)".
Based on this it contains a probably better workaround by avoiding the call to flatten_bezier in this situation. With it plsqldev.exe is able to start.
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #5 from Esme Povirk madewokherd@gmail.com --- Where did the NaNs come from? If the application added them to a path, we should see if native allows such a path to be built at all. If they were introduced by GdipWidenPath, there's probably a bug there.
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #6 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 78523 --> http://bugs.winehq.org/attachment.cgi?id=78523 plsql-widen_cap-adds-NaN_better-workaround.txt
(In reply to Esme Povirk from comment #5)
Where did the NaNs come from? If the application added them to a path, we should see if native allows such a path to be built at all. If they were introduced by GdipWidenPath, there's probably a bug there.
GdipWidenPath calls widen_open_figure, which calls widen_cap. Unfortunety in widen_cap the branch LineCapRound is taken, and segment_length gets a value of 0.0, which causes dx and dy to receive the NaN because of a division by zero, which gets used in the following calls to add_path_list_node.
In widen_cap are more uses of segment_length in the other branches, which may also be vulnerable.
The now attached file contains a workaround which avoids using this branch when segment_length is zero.
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #7 from Esme Povirk madewokherd@gmail.com --- That work-around makes sense to me. Maybe we should move the segment_dx/segment_dy calculation outside the switch so we don't have to duplicate this logic.
It will mean we don't draw the line cap when we might have previously. So that may still leave a regression, but I'd rather confirm that before working on it so we have a real test case.
I guess the solution would be to trace the polygon back further if the distance from endpoint is "too small", but I guess "too small" depends on floating point precision, so I'm not too sure how to figure that out. And I don't think we currently pass enough information to widen_cap to actually do that.
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #8 from Esme Povirk madewokherd@gmail.com --- Are endpoint and nextpoint precisely equal? Perhaps another approach would be to filter out any 0-length line segments in GdipWidenPath by removing points, before or in the loop over them.
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #9 from Esme Povirk madewokherd@gmail.com --- It might even be worth checking whether native GdipFlattenPath does this. Probably not, but if it did, that'd make it easier.
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #10 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 78539 --> http://bugs.winehq.org/attachment.cgi?id=78539 plsql-58203-testcase.patch
I hope this is of some help - I could extract a minimal testcase which triggers the same memory usage. For this to work the floating pont exceptions need to get disabled, I guess like Delphi programs do by default.
http://bugs.winehq.org/show_bug.cgi?id=58203
--- Comment #11 from Esme Povirk madewokherd@gmail.com --- Doesn't seem like native prevents repeated paths in any earlier step. MR sent filtering them out in GdipWidenPath: https://gitlab.winehq.org/wine/wine/-/merge_requests/8069
-
WineHQ Bugzilla