Dan Kegel wrote:
http://kegel.com/wine/valgrind/logs/ is updated as usual, this time with all of the log files I used to generate.
... listview seems genuinely improved: http://kegel.com/wine/valgrind/logs/2009-10-22-19.57/vg-comctl32_listview.tx... is a lot shorter than http://kegel.com/wine/valgrind/logs/2009-10-21-19.42/vg-comctl32_listview.tx...
I think a reason of EDIT_UnlockBuffer() warning found:
Invalid read of size 4 at EDIT_UnlockBuffer (edit.c:1219) by EditWndProc_common (edit.c:5393) by EditWndProcA (edit.c:5406) by ??? (library.h:159) by call_window_proc (winproc.c:469) by CallWindowProcA (winproc.c:2295) by CallWindowProcT (listview.c:1425) by EditLblWndProcT (listview.c:11279) by EditLblWndProcA (listview.c:11321) by ??? (library.h:159) by call_window_proc (winproc.c:469) by CallWindowProcA (winproc.c:2295) by editbox_subclass_proc (listview.c:576) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_CallProcWtoA (winproc.c:1279) by WINPROC_call_window (winproc.c:2216) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageW (message.c:2605) Address 0x7f03fba4 is not stack'd, malloc'd or (recently) free'd
This is caused by destruction through WM_CLOSE that we send on Killfocus event through subclass procedure. The sequence looks like: 1) SetFocus(); 2) WM_KILLFOCUS at Edit wndpoc; 3) WM_COMMAND (EN_KILLFOCUS) from Edit to listview 4) WM_CLOSE from listview to edit 5) Edit destroyed in default procedure 6) returning from edit killfocus handler edit data EDITSTATE already freed, but es still contains pointer to its location.
Attached patch should fix this, looks like IsWindow is fast enough to call it every time but maybe somebody knows better way.