Let's just say, for grins, that we applied a patch that made heap corruption fatal under WINEDEBUG=warn+heap, e.g.
--- a/dlls/ntdll/heap.c +++ b/dlls/ntdll/heap.c @@ -909,6 +909,7 @@ static BOOL HEAP_ValidateInUseArena( con WARN( "Heap %p: unaligned arena pointer %p\n", subheap->heap, pArena ); if ( TRACE_ON(heap) ) HEAP_Dump( subheap->heap ); + assert( FALSE ); } return FALSE; } @@ -924,6 +925,7 @@ static BOOL HEAP_ValidateInUseArena( con WARN("Heap %p: invalid in-use arena magic for %p\n", subheap->heap, pArena ); if (TRACE_ON(heap)) HEAP_Dump( subheap->heap ); + assert( FALSE ); } return FALSE; }
How many tests would that break? Any guesses? Scroll down for the answer:
25! Here's the output of WINEDEBUG=warn+heap make -k test piped through grep make.*Error:
make[2]: *** [alloc.ok] Error 134 make[2]: *** [pipe.ok] Error 1 make[2]: *** [systray.ok] Error 6 make[2]: *** [thread.ok] Error 9 make[2]: *** [security.ok] Error 1 make[1]: *** [advapi32/tests/__test__] Error 2 make[2]: *** [info.ok] Error 134 make[1]: *** [ntdll/tests/__test__] Error 2 make[2]: *** [heap.ok] Error 134 make[2]: *** [change.ok] Error 2 make[2]: *** [heap.ok] Error 5 make[2]: *** [util.ok] Error 134 make[1]: *** [msvcrt/tests/__test__] Error 2 make[1]: *** [snmpapi/tests/__test__] Error 2 make[2]: *** [apibuf.ok] Error 134 make[1]: *** [netapi32/tests/__test__] Error 2 make[2]: *** [device.ok] Error 4 make[1]: *** [d3d9/tests/__test__] Error 2 make[2]: *** [moniker.ok] Error 134 make[2]: *** [toolhelp.ok] Error 8 make[2]: *** [webbrowser.ok] Error 134 make[1]: *** [shdocvw/tests/__test__] Error 2 make[2]: *** [input.ok] Error 64 make[2]: *** [editor.ok] Error 5 make[1]: *** [riched20/tests/__test__] Error 2 make[2]: *** [mixer.ok] Error 10 make[2]: *** [msg.ok] Error 18 make[2]: *** [shellpath.ok] Error 3 make[2]: *** [class.ok] Error 2 make[2]: *** [comm.ok] Error 3 make[2]: *** [vartype.ok] Error 134 make[1]: *** [oleaut32/tests/__test__] Error 2 make[2]: *** [parser.ok] Error 134 make[1]: *** [setupapi/tests/__test__] Error 2 make[2]: *** [win.ok] Error 8 make[2]: *** [capture.ok] Error 134 make[1]: *** [dsound/tests/__test__] Error 2 make[2]: *** [htmldoc.ok] Error 134 make[2]: *** [timer.ok] Error 1 make[2]: *** [mci.ok] Error 134 make[1]: *** [mshtml/tests/__test__] Error 2 make[2]: *** [font.ok] Error 26 make[1]: *** [gdi32/tests/__test__] Error 2 make[1]: *** [kernel32/tests/__test__] Error 2 make[2]: *** [wave.ok] Error 8 make[1]: *** [winmm/tests/__test__] Error 2 make[2]: *** [server.ok] Error 4 make[1]: *** [rpcrt4/tests/__test__] Error 2 make[2]: *** [dde.ok] Error 5 make[1]: *** [user32/tests/__test__] Error 2 make[2]: *** [shlexec.ok] Error 35 make[1]: *** [shell32/tests/__test__] Error 2 make[1]: *** [ole32/tests/__test__] Error 2
I wonder if some of these tests are themselves buggy such that they pass on Wine by accident (without this patch) but fail on Windows? - Dan
Hi Dan,
Dan Kegel schreef:
25! Here's the output of WINEDEBUG=warn+heap make -k test piped through grep make.*Error:
make[2]: *** [alloc.ok] Error 134 make[2]: *** [pipe.ok] Error 1 make[2]: *** [systray.ok] Error 6 make[2]: *** [thread.ok] Error 9 make[2]: *** [security.ok] Error 1 make[1]: *** [advapi32/tests/__test__] Error 2 make[2]: *** [info.ok] Error 134 make[1]: *** [ntdll/tests/__test__] Error 2 make[2]: *** [heap.ok] Error 134 make[2]: *** [change.ok] Error 2 make[2]: *** [heap.ok] Error 5 make[2]: *** [util.ok] Error 134 make[1]: *** [msvcrt/tests/__test__] Error 2 make[1]: *** [snmpapi/tests/__test__] Error 2 make[2]: *** [apibuf.ok] Error 134 make[1]: *** [netapi32/tests/__test__] Error 2 make[2]: *** [device.ok] Error 4 make[1]: *** [d3d9/tests/__test__] Error 2 make[2]: *** [moniker.ok] Error 134 make[2]: *** [toolhelp.ok] Error 8 make[2]: *** [webbrowser.ok] Error 134 make[1]: *** [shdocvw/tests/__test__] Error 2 make[2]: *** [input.ok] Error 64 make[2]: *** [editor.ok] Error 5 make[1]: *** [riched20/tests/__test__] Error 2 make[2]: *** [mixer.ok] Error 10 make[2]: *** [msg.ok] Error 18 make[2]: *** [shellpath.ok] Error 3 make[2]: *** [class.ok] Error 2 make[2]: *** [comm.ok] Error 3 make[2]: *** [vartype.ok] Error 134 make[1]: *** [oleaut32/tests/__test__] Error 2 make[2]: *** [parser.ok] Error 134 make[1]: *** [setupapi/tests/__test__] Error 2 make[2]: *** [win.ok] Error 8 make[2]: *** [capture.ok] Error 134 make[1]: *** [dsound/tests/__test__] Error 2 make[2]: *** [htmldoc.ok] Error 134 make[2]: *** [timer.ok] Error 1 make[2]: *** [mci.ok] Error 134 make[1]: *** [mshtml/tests/__test__] Error 2 make[2]: *** [font.ok] Error 26 make[1]: *** [gdi32/tests/__test__] Error 2 make[1]: *** [kernel32/tests/__test__] Error 2 make[2]: *** [wave.ok] Error 8 make[1]: *** [winmm/tests/__test__] Error 2 make[2]: *** [server.ok] Error 4 make[1]: *** [rpcrt4/tests/__test__] Error 2 make[2]: *** [dde.ok] Error 5 make[1]: *** [user32/tests/__test__] Error 2 make[2]: *** [shlexec.ok] Error 35 make[1]: *** [shell32/tests/__test__] Error 2 make[1]: *** [ole32/tests/__test__] Error 2
I wonder if some of these tests are themselves buggy such that they pass on Wine by accident (without this patch) but fail on Windows
Did you run them with a -j flag? It would be less confusing to see it without it. In either case I will take a look at the winmm/dsound tests either tomorrow or when I get back from excursion in 9 days. I don't think that the heap test failing would be a real failure though, it probably tests such behavior.
Cheers, Maarten.
On 10/26/07, Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Did you run them with a -j flag?
Nope. Yeah, things happened kind of out of order, no idea why.
It would be less confusing to see it without it. In either case I will take a look at the winmm/dsound tests either tomorrow or when I get back from excursion in 9 days. I don't think that the heap test failing would be a real failure though, it probably tests such behavior.
Have a look at http://bugs.winehq.org/show_bug.cgi?id=10179 and see if you still think so! - Dan
"Dan Kegel" dank06@kegel.com writes:
Have a look at http://bugs.winehq.org/show_bug.cgi?id=10179 and see if you still think so!
That's not heap corruption, it's the expected behavior of GlobalHandle when called with a pointer to a moveable block.
On 10/26/07, Alexandre Julliard julliard@winehq.org wrote:
That's not heap corruption, it's the expected behavior of GlobalHandle when called with a pointer to a moveable block.
Good - then the bug is just that Wine is generating a spurious scary warning. How can we either suppress that warning, or make it more accurate?
"Dan Kegel" dank@kegel.com writes:
On 10/26/07, Alexandre Julliard julliard@winehq.org wrote:
That's not heap corruption, it's the expected behavior of GlobalHandle when called with a pointer to a moveable block.
Good - then the bug is just that Wine is generating a spurious scary warning. How can we either suppress that warning, or make it more accurate?
Well, that's why it's a WARN, it indicates that something may be wrong, but may also be a normal failure. If it were only displayed in cases where there's a real error it would be an ERR (and it actually is an ERR when called for internal pointers that we know should be valid).