http://kegel.com/wine/valgrind/logs/2009-12-05-01.15/ shows the same results as http://kegel.com/wine/valgrind/logs/2009-12-04-18.45/ but with a looser filter, i.e. I now even show files whose only sin is a memory leak (in the past, I had suppressed those because I cared more about non-leak errors).
It also suppresses several more persistent sources of warnings, for which I've filed a couple bugs: http://bugs.winehq.org/show_bug.cgi?id=20917 http://bugs.winehq.org/show_bug.cgi?id=20919
With those changes, I now see 457 non-leak errors, (~134 of which are due to the fresh regression http://bugs.winehq.org/show_bug.cgi?id=20920 ) and 1560 leak errors (~300 of which are due to ntlm_auth, which I'm still trying to suppress), in the wine conformance test suite.
Hi Dan,
in vg-ddraw-d3d.txt: Conditional jump or move depends on uninitialised value(s) at ??? (in /dev/zero) by surface_load_ds_location (surface.c:4504) by IWineD3DDeviceImpl_SetDepthStencilSurface (device.c:6273) etc
It seems that this happens in a function that the compiler inlined. Can you compile Wine with -O0 to have more debug info?
2009/12/5 Stefan Dösinger stefandoesinger@gmx.at:
That's the same as bug 20917. For some reason Valgrind doesn't like immediate mode drawing. Going by http://wiki.winehq.org/Wine_and_Valgrind, it probably doesn't like nVidia's mprotect() tricks.
On Sat, Dec 5, 2009 at 10:00 AM, Stefan Dösinger stefandoesinger@gmx.at wrote:
That is already -O0. I think that's a driver function or a trampoline or something. Here it is with the addresses:
=>0 0x0de219b1 (0x7f21fa08) 1 0x106c07b9 surface_load_ds_location+0xa49(iface=0x7f0e74f8, context=0x7f0e6370, location=4194304) [dlls/wined3d/surface.c:4505] in wined3d (0x7f21fb18) 2 0x1061efb7 IWineD3DDeviceImpl_SetDepthStencilSurface+0x17c(iface=0x7f08bbf0, pNewZStencil=0x7f343168) [dlls/wined3d/device.c:6274] in wined3d (0x7f21fb68)
That area, 0xde20000, does not show up in the load map printed with the backtrace. - Dan
On Sat, Dec 5, 2009 at 7:39 AM, Dan Kegel dank@kegel.com wrote:
And http://kegel.com/wine/valgrind/logs/2009-12-05-08.01/ fixes a problem where I hadn't really applied the most recent dozen or so suppressions (whoops). That shows 1439 leaks and 395 non-leak warnings.
I'm going to do one more quick run today, disabling three more d3d tests that crash, and (riskily) running with -j2 (I seem to recall this gave reasonable results and saved a lot of time, not sure if that was with my old locking patch or not.)
On Sat, Dec 5, 2009 at 1:24 PM, Dan Kegel dank@kegel.com wrote:
I'm going to do one more quick run today, disabling three more d3d tests that crash, and (riskily) running with -j2
Done, see http://kegel.com/wine/valgrind/logs/2009-12-05-15.20/
I checked in my recent script changes to http://code.google.com/p/winezeug/source/detail?r=851 I had to update the whitelisting alarm.c that I wrote for patchwatcher a bit. Valgrinding now takes just under three hours with -j2. Results are roughly as good as -j1.
One extra change I made was to increase the redzone from the default of 8 bytes to 32 bytes. This probably explains the extra error caught in http://kegel.com/wine/valgrind/logs/2009-12-05-15.20/diff-ntdll_heap.txt
Not sure how to explain http://kegel.com/wine/valgrind/logs/2009-12-05-15.20/diff-advapi32_lsa.txt yet, though. - Dan
On Sat, Dec 5, 2009 at 7:39 AM, Dan Kegel dank@kegel.com wrote:
I had a build problem (script error) that made test results from Monday through this morning funny. I reran after fixing the error; results at http://kegel.com/wine/valgrind/logs/2009-12-09-17.02/
I now count 289 non-leak errors and 981 leak errors. Some of the remaining reported errors in msi are probably my fault - I'm running them in parallel. Probably making them all use different data files would do the trick... - Dan
On Wed, Dec 9, 2009 at 9:01 PM, Dan Kegel dank@kegel.com wrote:
I was wondering why you were getting so many msi test failures and errors! Now I know. Yes, the msi tests can't be run in parallel, even on windows. Vincent stated that he thinks the StorageImpl_Construct bug is fixed, yet I'm still seeing the errors. Vincent, can you take a look at the results?
Thanks, James Hawkins
On Wed, Dec 9, 2009 at 9:51 PM, James Hawkins truiken@gmail.com wrote:
Oops, spoke too soon. Thanks for fixing the problem Vincent! I guess we can close http://bugs.winehq.org/show_bug.cgi?id=20920 now.
James
On Wed, Dec 9, 2009 at 11:52 PM, James Hawkins truiken@gmail.com wrote:
That wasn't me; I just removed the fixed code afterwards. ;)
On Wed, Dec 9, 2009 at 9:51 PM, James Hawkins truiken@gmail.com wrote:
What if I use a different msi database for each test? That'd be easy.
Otherwise I'll take them out of my whitelist.
Yes, that seems ok now, thanks. - Dan
On Thu, Dec 10, 2009 at 2:28 AM, Dan Kegel dank@kegel.com wrote:
Yea, an easy fix would be to change the msifile constant by appending the name of the test or something. That should give a different package for each test. A more proper fix would be to have the database/package generator function create a temp filename for the package and give that back to you, but it hardly seems worth the effort.
On Wed, Dec 9, 2009 at 9:51 PM, James Hawkins truiken@gmail.com wrote:
The only whitelisted msi tests were source and record; I've removed them from the whitelist, see http://code.google.com/p/winezeug/source/detail?r=866
Updated results (with yesterday's git) are at http://kegel.com/wine/valgrind/logs/2009-12-10-03.53/ As expected, there are few differences except in one file, http://kegel.com/wine/valgrind/logs/2009-12-10-03.53/diff-msi_record.txt where nearly all the errors are gone, there's just one leak left in that file: http://kegel.com/wine/valgrind/logs/2009-12-10-03.53/vg-msi_record.txt
Before: 289 non-leak errors, 981 leak errors. After: 266 non-leak errors, 982 leak errors.
Most of the errors are in these few files:
vg-kernel32_change.txt 29 vg-rpcrt4_ndr_marshall.txt 29 vg-ntdll_heap.txt 31 vg-ntdll_reg.txt 33 vg-oleaut32_vartest.txt 39 vg-riched20_txtsrv.txt 39 vg-shell32_shlfileop.txt 40 vg-user32_dde.txt 48 vg-msi_db.txt 76 vg-secur32_ntlm.txt 79 vg-riched20_editor.txt 88 vg-jscript_run.txt 239
Those ntdll_heap results (soon to move to kernel32_heap) are all expected and I will suppress them in the next tally. - Dan
-
Dan Kegel -
Henri Verbeet -
James Hawkins -
Stefan Dösinger -
Vincent Povirk