valgrind results for 20 October 2009

[Dan Kegel]

Fresh Valgrind results for the wine conformance tests are available at

http://kegel.com/wine/valgrind/logs/2009-10-20-01.09/

This is from about six hours ago, so it doesn't include Alexandre's
coming commits for the day.   The code was compiled with
-O0 -g to give detailed stacks.

The run uses current valgrind from svn with a couple patches,
mainly John Reiser's recent patch to make mmap/mprotect
behave (needed since the merge of mac support).

ole32/marshal.c hung, so I don't have any results from past that.

I suppressed some of the benign warnings, but there are surely
a bunch left (e.g. kernel32 tests of freeing an invalid pointer
still show up), so you have to look at the test source before
deciding whether a warning is valid.

I suppressed all the "possible" leaks, so any leak that shows up
in the log is quite probably a real leak (though possibly a benign one).

Please have a look to see if your favorite module has easily-fixable
problems.

[Nikolay Sivov]

Dan Kegel wrote:
> Fresh Valgrind results for the wine conformance tests are available at
>
> http://kegel.com/wine/valgrind/logs/2009-10-20-01.09/
>
> This is from about six hours ago, so it doesn't include Alexandre's
> coming commits for the day.   The code was compiled with
> -O0 -g to give detailed stacks.
>
> The run uses current valgrind from svn with a couple patches,
> mainly John Reiser's recent patch to make mmap/mprotect
> behave (needed since the merge of mac support).
>
> ole32/marshal.c hung, so I don't have any results from past that.
>
> I suppressed some of the benign warnings, but there are surely
> a bunch left (e.g. kernel32 tests of freeing an invalid pointer
> still show up), so you have to look at the test source before
> deciding whether a warning is valid.
>
> I suppressed all the "possible" leaks, so any leak that shows up
> in the log is quite probably a real leak (though possibly a benign one).
>
> Please have a look to see if your favorite module has easily-fixable
> problems.

Hi, Dan.

I'll certainly look at it. Could you provide a whole valgrind command 
line you're using, assuming that I have
3.3.1 not svn build.

Are you intentionally dropped user32 tests?

P.S. Is it possible to run such check each week, or at least some days 
before release?

[Austin English]

On Tue, Oct 20, 2009 at 9:59 AM, Nikolay Sivov  wrote:
> Dan Kegel wrote:
> Are you intentionally dropped user32 tests?

"ole32/marshal.c hung, so I don't have any results from past that."

[Nikolay Sivov]

Austin English wrote:
> On Tue, Oct 20, 2009 at 9:59 AM, Nikolay Sivov  wrote:
> > Dan Kegel wrote:
> > Are you intentionally dropped user32 tests?
>
> "ole32/marshal.c hung, so I don't have any results from past that."

Ah, sorry. I thought it's separate, each run.

[Dan Kegel]

On Tue, Oct 20, 2009 at 7:59 AM, Nikolay Sivov  wrote:
> Could you provide a whole valgrind command line
> you're using, assuming that I have 3.3.1 not svn build.

Try something like

cd dlls/ole32/tests
valgrind --trace-children=yes --workaround-gcc296-bugs=yes --track-origins=yes
-q ../../../wine ole32_test.exe.so marshal.c

I'll update the scripts I use; the old ones are in winezeug/valgrind.
> Are you intentionally dropped user32 tests?

No, the ole32 marshal tests hung, so I stopped there.  I'll skip them next run.
> P.S. Is it possible to run such check each week, or at least some days
> before release?

I'll try to do automated builds every day.
- Dan

[Nikolay Sivov]

Dan Kegel wrote:
> On Tue, Oct 20, 2009 at 7:59 AM, Nikolay Sivov  wrote:
> > Could you provide a whole valgrind command line
> > you're using, assuming that I have 3.3.1 not svn build.
>
> Try something like
>
> cd dlls/ole32/tests
> valgrind --trace-children=yes --workaround-gcc296-bugs=yes --track-origins=yes
> -q ../../../wine ole32_test.exe.so marshal.c
>
> I'll update the scripts I use; the old ones are in winezeug/valgrind.

Unfortunately it seems I don't have --track-origins parameter using 3.3.1.

Do I need any kind of special build with valgrind support or it will 
work with any binary?
Is WINETEST_WRAPPER found in wiki needed?
> > P.S. Is it possible to run such check each week, or at least some days
> > before release?
>
> I'll try to do automated builds every day.
> - Dan

That's great.

[Dan Kegel]

On Tue, Oct 20, 2009 at 11:35 AM, Nikolay Sivov  wrote:
> Unfortunately it seems I don't have --track-origins parameter using 3.3.1.

Life is much more fun with that option.   I'll post instructions for building
valgrind from svn tonight or so.
> Do I need any kind of special build with valgrind support or it will work
> with any binary?

Make sure include/config.h has the VALGRIND_ defines not commented out;
if it does, you may need to install /usr/include/valgrind and
reconfigure and rebuild wine.
> Is WINETEST_WRAPPER found in wiki needed?

Only for "make test" or "runtest".  You don't need it if you're
running the foo_test_exe.so by hand.
- Dan

[Henri Verbeet]

2009/10/20 Dan Kegel :
> coming commits for the day.   The code was compiled with
> -O0 -g to give detailed stacks.

Does that still inline functions? I was looking at this one (and the
resulting crash?):

Invalid write of size 4
    at  ??? (in /dev/zero)
    by  init_format_filter_info (utils.c:947)
    by  initPixelFormats (utils.c:1132)
    by  InitAdapters (directx.c:4721)
    by  WineDirect3DCreate (wined3d_main.c:71)
    by  Direct3DCreate8 (d3d8_main.c:48)
    by  test_refcount (device.c:316)
    by  func_device (device.c:1484)
    by  run_test (test.h:535)
    by  main (test.h:585)
  Address 0x10506c54 is not stack'd, malloc'd or (recently) free'd

but from the log it's not entirely clear to me where the actual write happens.