http://bugs.winehq.org/show_bug.cgi?id=20692
Summary: Probable benign window title leak Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
This is another case of 'a leak so small it doesn't matter'. I think it only happens once per window, and only when the window doesn't get an NCDESTROY message before exiting. I'm filing it and marking it WONTFIX so the valgrind suppression I create can point to a bug report for explanation.
http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/vg-user32_msg.txt says user32_test.exe.so msg.c leaks like this:
22 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by DEFWND_SetTextA (defwnd.c:98) by DefWindowProcA (defwnd.c:834) by MsgCheckProc (msg.c:7274) by MsgCheckProcA (msg.c:7283) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2223) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageA (message.c:2627) by WIN_CreateWindowEx (win.c:1342) by CreateWindowExA (win.c:1541)
And http://kegel.com/wine/chromium/valgrind-logs/base_unittests/MessageLoopTest.... says that base_unittests.exe --gtest_filter=MessageLoopTest.RecursiveDenial2 and a couple others leak as follows:
8 bytes in 4 blocks are definitely lost in loss record 87 of 1,034 at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by DEFWND_SetTextW (defwnd.c:134) by DefWindowProcW (defwnd.c:981) by StaticWndProc_common (static.c:520) by StaticWndProcW (static.c:630) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2214) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageW (message.c:2605) by WIN_CreateWindowEx (win.c:1340) by CreateWindowExW (win.c:1573) by DIALOG_CreateControls32 (dialog.c:276) by DIALOG_CreateIndirect (dialog.c:691) by DialogBoxIndirectParamAorW (dialog.c:871) by DialogBoxIndirectParamW (dialog.c:892) by MessageBoxIndirectW (msgbox.c:527) by MessageBoxExW (msgbox.c:451) by MessageBoxW (msgbox.c:406)
We can reopen this bug if the leak turns out to be an actual problem.
http://bugs.winehq.org/show_bug.cgi?id=20692
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX
--- Comment #1 from Dan Kegel dank@kegel.com 2009-11-13 15:38:04 --- Not likely to hurt any real app.
http://bugs.winehq.org/show_bug.cgi?id=20692
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-13 21:57:43 --- Closing then
http://bugs.winehq.org/show_bug.cgi?id=20692
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com 2009-11-13 23:13:31 --- (In reply to comment #1)
Not likely to hurt any real app.
It affects any app that uses ListView for example - any window that blocks WM_NCDESTROY flow to default procedure. It's a real problem and a leak with obvious reason. Dan, please consider to reopen this.
A fix is two-line: --- HeapFree( GetProcessHeap(), 0, wndPtr->text ); wndPtr->text = NULL; ---
Should be placed in WIN_DestroyWindow(). I've already done that for scrollinfo.
I'll prepare patches both for ListView and destroy sequence (I want ListView to call default procedure after its own releasing).
http://bugs.winehq.org/show_bug.cgi?id=20692
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|WONTFIX |
--- Comment #4 from Dan Kegel dank@kegel.com 2009-11-13 23:49:18 --- ok, thanks!
http://bugs.winehq.org/show_bug.cgi?id=20692
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2009-11-14 09:03:24 --- Created an attachment (id=24731) --> (http://bugs.winehq.org/attachment.cgi?id=24731) Free window text if it isn't freed yet on WM_NCDESTROY
Hi, Dan.
This is a patch for that. After that window text is always released, I don't think we should remove WM_NCDESTROY from default procedure cause it could break message handling if someone tries to send this message directly to window.
http://bugs.winehq.org/show_bug.cgi?id=20692
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com 2009-11-15 03:54:37 --- Patch sent:
http://www.winehq.org/pipermail/wine-patches/2009-November/081392.html
http://bugs.winehq.org/show_bug.cgi?id=20692
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-16 12:38:36 --- (In reply to comment #5)
This is a patch for that. After that window text is always released, I don't think we should remove WM_NCDESTROY from default procedure cause it could break message handling if someone tries to send this message directly to window.
In which way it could break message handling?
http://bugs.winehq.org/show_bug.cgi?id=20692
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com 2009-11-16 19:50:51 --- (In reply to comment #7)
(In reply to comment #5)
This is a patch for that. After that window text is always released, I don't think we should remove WM_NCDESTROY from default procedure cause it could break message handling if someone tries to send this message directly to window.
In which way it could break message handling?
'if someone tries to send this message directly to window.'
This is fixed by commit 1b96626750e8c8be17ca3c93ed23c7b29a5e8e36.
http://bugs.winehq.org/show_bug.cgi?id=20692
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2009-12-04 12:16:27 --- Closing bugs fixed in 1.1.34.
-
wine-bugs＠winehq.org