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(a)gmx.at>:
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?
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(a)gmx.at> wrote:
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?
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(a)kegel.com> wrote:
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
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(a)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(a)kegel.com> wrote:
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.
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(a)kegel.com> wrote:
On Sat, Dec 5, 2009 at 7:39 AM, Dan Kegel <dank(a)kegel.com> wrote:
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.
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
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(a)gmail.com> wrote:
On Wed, Dec 9, 2009 at 9:01 PM, Dan Kegel <dank(a)kegel.com> wrote:
On Sat, Dec 5, 2009 at 7:39 AM, Dan Kegel <dank(a)kegel.com> wrote:
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.
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
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?
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(a)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
That wasn't me; I just removed the fixed code afterwards. ;) -- Vincent Povirk
On Wed, Dec 9, 2009 at 9:51 PM, James Hawkins <truiken(a)gmail.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.
What if I use a different msi database for each test? That'd be easy. Otherwise I'll take them out of my whitelist.
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?
Yes, that seems ok now, thanks. - Dan
On Thu, Dec 10, 2009 at 2:28 AM, Dan Kegel <dank(a)kegel.com> wrote:
On Wed, Dec 9, 2009 at 9:51 PM, James Hawkins <truiken(a)gmail.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.
What if I use a different msi database for each test? That'd be easy.
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.
Otherwise I'll take them out of my whitelist.
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?
Yes, that seems ok now, thanks. - Dan
On Wed, Dec 9, 2009 at 9:51 PM, James Hawkins <truiken(a)gmail.com> wrote:
Some of the remaining reported errors in msi are probably my fault - I'm running them in parallel. 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.
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
participants (5)
-
Dan Kegel -
Henri Verbeet -
James Hawkins -
Stefan Dösinger -
Vincent Povirk