[Bug 58203] New: PL/SQL Developer: All system memory gets eaten
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(a)winehq.org Reporter: robertdejager(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org Regression SHA1| |510ad5578a487c4d3e35a330bd5 | |d92cfeabeebc7 Keywords| |download, regression --- Comment #1 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Creating a tnsnames.ora seems not neccessary. A git bisect points here: commit 510ad5578a487c4d3e35a330bd5d92cfeabeebc7 Author: Esme Povirk <esme(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #2 from Bernhard Übelacker <bernhardu(a)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.) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |gdiplus -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #3 from Bernhard Übelacker <bernhardu(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #4 from Bernhard Übelacker <bernhardu(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #5 from Esme Povirk <madewokherd(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #6 from Bernhard Übelacker <bernhardu(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #7 from Esme Povirk <madewokherd(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #8 from Esme Povirk <madewokherd(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #9 from Esme Povirk <madewokherd(a)gmail.com> --- It might even be worth checking whether native GdipFlattenPath does this. Probably not, but if it did, that'd make it easier. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #10 from Bernhard Übelacker <bernhardu(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #11 from Esme Povirk <madewokherd(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |4ce7b713f8acc6afa4253bc07bc | |85cd8d7d02a44 --- Comment #12 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Merge request got committed, marking resolved fixed. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 --- Comment #13 from Robert de Jager <robertdejager(a)tutanota.com> --- Although I haven't had much to contribute, I just want to say I very much appreciate how all of you just get on it and solve the problem. You're awesome! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58203 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.9. -- 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