The curious Valgrind error
+ Conditional jump or move depends on uninitialised value(s) + at SetWindowPos (winpos.c:2034) + by LISTVIEW_UpdateSize (listview.c:9380) + by LISTVIEW_Size (listview.c:9320) + by LISTVIEW_WindowProc (listview.c:9949) + by (within /home/dank/wine-git/dlls/user32/user32.dll.so) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcAtoW (winproc.c:901) + by CallWindowProcA (winproc.c:2282) + by listview_subclass_proc (listview.c:231) + by (within /home/dank/wine-git/dlls/user32/user32.dll.so) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcWtoA (winproc.c:1267) + by WINPROC_call_window (winproc.c:2200) + by call_window_proc (message.c:1610) + by send_message (message.c:2434) + by SendMessageW (message.c:2557) + by DEFWND_DefWinProc (defwnd.c:746) + by DefWindowProcW (defwnd.c:1037) + by LISTVIEW_WindowProc (listview.c:9994) + by (within /home/dank/wine-git/dlls/user32/user32.dll.so) + Uninitialised value was created by a stack allocation + at LISTVIEW_UpdateSize (listview.c:9351)
started happening recently. Looking at LISTVIEW_UpdateSize, it seems clear that if SendMessageW( infoPtr->hwndHeader, HDM_LAYOUT, 0, (LPARAM)&hl ); fails for whatever reason, hl will be undefined, and that's what Valgrind is complaining about. Here's a patch that skips the rest of the function if that line fails; it makes Valgrind happy, and doesn't seem to hurt the conformance tests. Can somebody familiar with the code have a look at that function and explain what's going on here? Thanks! - Dan
I don't feel a maintainer of the listview but I have some experience with the code causing this problem
Dan Kegel wrote:
Can somebody familiar with the code have a look at that function and explain what's going on here?
With the current implementation of the header control, the only case when HDM_LAYOUT fails is when the header is not yet created. This may happen between the WM_NCCREATE and WM_CREATE messages (the header is created during the WM_CREATE). The test that triggers this sets an imagelist during this period (an application requires this to work). I'm not familiar enough with the code to know if it is correct that it triggers an UpdateSize or why it started recently. A solution, working even if we allow the HDM_LAYOUT to fail, could be to ZeroMemory(&wp) before the call. That way we have some sensible defaults if the call fails. Another, would be to create the header control on-demand like Windows does (see bug #4175), but I'm affraid, even with a very careful testing that would introduce some regressions.
Mikolaj Zalewski
-
Dan Kegel -
Mikołaj Zalewski