https://bugs.winehq.org/show_bug.cgi?id=36558
Bug ID: 36558 Summary: valgrind shows a definite leak in comctl32/tests/treeview.c Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs@winehq.org Reporter: austinenglish@gmail.com
==26061== 140 bytes in 1 blocks are definitely lost in loss record 620 of 921 ==26061== at 0x7BC4C6DF: notify_alloc (heap.c:255) ==26061== by 0x7BC50F23: RtlAllocateHeap (heap.c:1716) ==26061== by 0x4FE3841: ImageListImpl_CreateInstance (imagelist.c:3697) ==26061== by 0x4FDC1EA: ImageList_Create (imagelist.c:772) ==26061== by 0x505A37F: TREEVIEW_InitCheckboxes (treeview.c:2954) ==26061== by 0x505A6A5: TREEVIEW_Paint (treeview.c:3013) ==26061== by 0x5060D32: TREEVIEW_WindowProc (treeview.c:5817) ==26061== by 0x538D4F5: ??? (winproc.c:173) ==26061== by 0x538D66A: call_window_proc (winproc.c:244) ==26061== by 0x538E858: WINPROC_CallProcAtoW (winproc.c:603) ==26061== by 0x538FA49: CallWindowProcA (winproc.c:961) ==26061== by 0x4D435DF: TreeviewWndProc (treeview.c:315) ==26061== by 0x538D4F5: ??? (winproc.c:173) ==26061== by 0x538D66A: call_window_proc (winproc.c:244) ==26061== by 0x538F8B9: WINPROC_call_window (winproc.c:909) ==26061== by 0x5350859: DispatchMessageA (message.c:3948) ==26061== by 0x4D4B261: test_TVS_CHECKBOXES (treeview.c:1943) ==26061== by 0x4D4C651: func_treeview (treeview.c:2228) ==26061== by 0x4D51DB9: run_test (test.h:584) ==26061== by 0x4D521A8: main (test.h:654) ==26061==
https://bugs.winehq.org/show_bug.cgi?id=36558
--- Comment #1 from Austin English austinenglish@gmail.com --- A second one: ==26061== 560 bytes in 4 blocks are definitely lost in loss record 756 of 921 ==26061== at 0x7BC4C6DF: notify_alloc (heap.c:255) ==26061== by 0x7BC50F23: RtlAllocateHeap (heap.c:1716) ==26061== by 0x4FE3841: ImageListImpl_CreateInstance (imagelist.c:3697) ==26061== by 0x4FDC1EA: ImageList_Create (imagelist.c:772) ==26061== by 0x505A37F: TREEVIEW_InitCheckboxes (treeview.c:2954) ==26061== by 0x505FD23: TREEVIEW_StyleChanged (treeview.c:5495) ==26061== by 0x5060DE8: TREEVIEW_WindowProc (treeview.c:5838) ==26061== by 0x538D4F5: ??? (winproc.c:173) ==26061== by 0x538D66A: call_window_proc (winproc.c:244) ==26061== by 0x538E858: WINPROC_CallProcAtoW (winproc.c:603) ==26061== by 0x538FA49: CallWindowProcA (winproc.c:961) ==26061== by 0x4D435DF: TreeviewWndProc (treeview.c:315) ==26061== by 0x538D4F5: ??? (winproc.c:173) ==26061== by 0x538D66A: call_window_proc (winproc.c:244) ==26061== by 0x538F697: WINPROC_CallProcWtoA (winproc.c:858) ==26061== by 0x538F842: WINPROC_call_window (winproc.c:902) ==26061== by 0x534C11C: call_window_proc (message.c:2223) ==26061== by 0x534EFBA: send_message (message.c:3260) ==26061== by 0x534F5D8: SendMessageW (message.c:3454) ==26061== by 0x5381439: WIN_SetWindowLong (win.c:2515) ==26061==
https://bugs.winehq.org/show_bug.cgi?id=36558
--- Comment #2 from Austin English austinenglish@gmail.com --- The second leak also shows up in explorerframe/tests/nstc.c: ==27764== 140 bytes in 1 blocks are definitely lost in loss record 568 of 813 ==27764== at 0x7BC4C6DF: notify_alloc (heap.c:255) ==27764== by 0x7BC50F23: RtlAllocateHeap (heap.c:1716) ==27764== by 0x6725841: ImageListImpl_CreateInstance (imagelist.c:3697) ==27764== by 0x671E1EA: ImageList_Create (imagelist.c:772) ==27764== by 0x679C37F: TREEVIEW_InitCheckboxes (treeview.c:2954) ==27764== by 0x67A1D23: TREEVIEW_StyleChanged (treeview.c:5495) ==27764== by 0x67A2DE8: TREEVIEW_WindowProc (treeview.c:5838) ==27764== by 0x550E4F5: ??? (winproc.c:173) ==27764== by 0x550E66A: call_window_proc (winproc.c:244) ==27764== by 0x5510ABE: CallWindowProcW (winproc.c:981) ==27764== by 0x66CB9CE: ??? ==27764== by 0x550E4F5: ??? (winproc.c:173) ==27764== by 0x550E66A: call_window_proc (winproc.c:244) ==27764== by 0x5510803: WINPROC_call_window (winproc.c:900) ==27764== by 0x54CD11C: call_window_proc (message.c:2223) ==27764== by 0x54CFFBA: send_message (message.c:3260) ==27764== by 0x54D05D8: SendMessageW (message.c:3454) ==27764== by 0x5502439: WIN_SetWindowLong (win.c:2515) ==27764== by 0x55026BC: SetWindowLongW (win.c:2670) ==27764== by 0x66CDB2E: ??? ==27764==
https://bugs.winehq.org/show_bug.cgi?id=36558
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com --- I remember this thing. I tried to fix it once and it turned out it's not possible to properly maintain state imagelist because some applications rely on it not being destroyed (as i remember some app used imagelist from one treeview in another and it broke once i started to release it).
https://bugs.winehq.org/show_bug.cgi?id=36558
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX
--- Comment #4 from Austin English austinenglish@gmail.com --- (In reply to Nikolay Sivov from comment #3)
I remember this thing. I tried to fix it once and it turned out it's not possible to properly maintain state imagelist because some applications rely on it not being destroyed (as i remember some app used imagelist from one treeview in another and it broke once i started to release it).
I've marked it as intentional, thanks.
https://bugs.winehq.org/show_bug.cgi?id=36558
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |---
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- For now unmark it please. I have to look at it again, probably I can use refcount to make it work.
https://bugs.winehq.org/show_bug.cgi?id=36558
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |valgrind
https://bugs.winehq.org/show_bug.cgi?id=36558
--- Comment #6 from Austin English austinenglish@gmail.com --- (In reply to Nikolay Sivov from comment #5)
For now unmark it please. I have to look at it again, probably I can use refcount to make it work.
Sure.