Errors reported by valgrind, coverity, and our conformance test suite are all worth fixing... but fixing them *all* is like shovelling out the dung from an infinitely large barn. Various people have tried fixing one kind of error or the other, but maybe a combined attack, where we went module by module and fixed *all* of the valgrind, coverity, and conformance test errors might be more fruitful (or at least more satisfying). Such an attempt should probably start at the bottom, cleaning up modules in the order wineserver, ntdll, kernel32, gdi32, user32, ...
To that end, here are the combined known errors for the first few modules.
wineserver:
coverity: cv219 FORWARD_NULL UNINSPECTED set_console_input_info base/src/wine/server/console.c cv220 FORWARD_NULL UNINSPECTED connect_process_winstation base/src/wine/server/winstation.c
ntdll:
coverity: cv48 FORWARD_NULL UNINSPECTED RtlAllocateHandle base/src/wine/dlls/ntdll/handletable.c cv55 FORWARD_NULL UNINSPECTED RtlCreateEnvironment base/src/wine/dlls/ntdll/env.c cv227 NEGATIVE_RETURNS UNINSPECTED read_changes_apc base/src/wine/dlls/ntdll/directory.c cv248 NULL_RETURNS UNINSPECTED HEAP_FindFreeBlock base/src/wine/dlls/ntdll/heap.c cv343 REVERSE_INULL UNINSPECTED NtOpenSection base/src/wine/dlls/ntdll/virtual.c cv538 NULL_RETURNS UNINSPECTED HEApNtEnumerateSubKey base/src/wine/dlls/ntdll/reg.c cv644 REVERSE_INULL UNINSPECTED NtQueryInformationProcess base/src/wine/dlls/ntdll/process.c cv658 FORWARD_NULL RNS UNINSPECTED RtlQueryRegistryValues base/src/wine/dlls/ntdll/reg.cdlls/ole32/ole2.c
valgrind:
http://kegel.com/wine/valgrind/logs-2008-04-10/vg-ntdll_env.txt http://kegel.com/wine/valgrind/logs-2008-04-10/vg-ntdll_exception.txt http://kegel.com/wine/valgrind/logs-2008-04-10/vg-ntdll_file.txt
conformance tests: http://test.winehq.org/data/200804161000/#group_Wine:ntdll:change http://test.winehq.org/data/200804161000/#group_XP:ntdll:exception
There, that doesn't look too awful, does it? Only a few dozen little problems to solve and we'll have server and ntdll spic and span... and then on to the next module.
If we start with a small circle of pure modules, and vigorously defend the modules in that circle against regressions in any of valgrind, coverity, and conformance tests, we might make a noticable improvement in Wine's quality. - Dan
Dan Kegel wrote:
Errors reported by valgrind, coverity, and our conformance test suite are all worth fixing... but fixing them *all* is like shovelling out the dung from an infinitely large barn. Various people have tried fixing one kind of error or the other, but maybe a combined attack, where we went module by module and fixed *all* of the valgrind, coverity, and conformance test errors might be more fruitful (or at least more satisfying). Such an attempt should probably start at the bottom, cleaning up modules in the order wineserver, ntdll, kernel32, gdi32, user32, ...
Is this also the order of the most mature modules? It seems to make sense doing this kind of cleanup on the more stable parts first, since the fixes are more likely to be permanent.
Thanks, Scott Ritchie
On Thu, Apr 17, 2008 at 5:03 PM, Scott Ritchie scott@open-vote.org wrote:
Such an attempt should probably start at the bottom, cleaning up modules in the order wineserver, ntdll, kernel32, gdi32, user32, ...
Is this also the order of the most mature modules? It seems to make sense doing this kind of cleanup on the more stable parts first, since the fixes are more likely to be permanent.
Yes, I think so (though user32 can't quite be called fully stable).
Doing it bottom-up is also natural because otherwise we'd see lots of lower-level module errors while valgrinding or running conformance tests on upper-level modules.
-
Dan Kegel -
Scott Ritchie