http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/ is the first full run with the heap tail check enabled.
Here are the first few new problems it found.
Somehow, it found a bunch of invalid reads in http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_crypt.txt all in a function called test_incorrect_api_usage(). Offhand that seems like something to suppress.
The invalid write I already posted about is in http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advapi32_lsa.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_lsa.txt
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advpack_files.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advpack_files.txt show an off-by-one buffer size issue (forgot to include space for nul char) in advpack (fix should be easy, anybody can grab this): Invalid write of size 2 at strcpyW (unicode.h:224) by lstrcpyW (string.c:104) by AdvInstallFileW (files.c:283) by AdvInstallFileA (files.c:216) by test_AdvInstallFile (files.c:513) Address 0x7f03d12e is 0 bytes after a block of size 30 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by AdvInstallFileW (files.c:282) by AdvInstallFileA (files.c:216) by test_AdvInstallFile (files.c:513)
http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt show a more inscrutable error: Invalid write of size 4 at TAB_SetCurSel (tab.c:255) by TAB_WindowProc (tab.c:3367) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_CallProcAtoW (winproc.c:1023) by CallWindowProcA (winproc.c:2299) by tabSubclassProcess (tab.c:404) 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 test_getters_setters (tab.c:752) by func_tab (tab.c:1174) by run_test (test.h:535) by main (test.h:585) Address 0x7f044098 is not stack'd, malloc'd or (recently) free'd
Nikolay touched that code back in March, perhaps he should have a look.
etc. etc. Lots of triage to do. It'd be nice if somebody could volunteer to go through these, file bugs, and assign provision blame using 'git blame'... - Dan