Student preparing for GSoC

[Kieran Duggan]

So I'm trying to run the tests with valgrind to find memory leaks but when
I use valgrind I end up getting output looking something like this
==14135== 288 (256 direct, 32 indirect) bytes in 1 blocks are definitely
lost in loss record 166 of 278
==14135==    at 0x442EB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14135==    by 0x96B50B9: ??? (in
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)
==14135==    by 0x96B5829: ??? (in
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)
==14135==    by 0x96B6D4A: ??? (in
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)
==14135==    by 0x96BC19B: ??? (in
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)
==14135==    by 0x98E3A9B: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.0)

but this isn't nearly as useful as the output I see on bugzilla, which
includes function calls and such
I tried recompiling my build with valgrind installed on my computer
and checked to be sure that the make config was detected it with
grep VALGRIND include/config.h and I get

#define HAVE_VALGRIND_MEMCHECK_H 1
#define HAVE_VALGRIND_VALGRIND_H 1

so I don't think that is the problem.

It seems to me like valgrind is expecting there to be some flags or
something for it to find but they aren't there.
Can anyone offer some assistance?

On Mon, Mar 19, 2018 at 5:51 AM, Henri Verbeet <hverbeet at gmail.com> wrote:

> On 19 March 2018 at 10:01, Kieran Duggan <kieranduggan15 at gmail.com> wrote:
> > Yes that is very useful!
> > I took a look at the first one I saw on the list. It goes:
> >
> > ==3551== 8 bytes in 1 blocks are definitely lost in loss record 63 of 766
> > ==3551==    at 0x7BC51061: notify_alloc (heap.c:254)
> > ==3551==    by 0x7BC5554F: RtlAllocateHeap (heap.c:1716)
> > ==3551==    by 0x5C85281: XAudio2Create (xaudio_dll.c:2159)
> > ==3551==    by 0x4A1B741: func_xaudio2 (xaudio2.c:1150)
> > ==3551==    by 0x4A1C74F: run_test (test.h:603)
> > ==3551==    by 0x4A1CBAD: main (test.h:687)
> > ==3551==
> >
> > To fix it I looked at the XAudio2Create function and noticed that
> > IClassFactory *cf was assigned in the call
> > make_xaudio2_factory(&IID_IClassFactory, (void**)&cf);
> > which contains
> > struct xaudio2_cf *ret = HeapAlloc(GetProcessHeap(), 0, sizeof(struct
> > xaudio2_cf));
> >
> > Later in the code IClassFactory_Release(cf); is used, but this wouldn't
> free
> > up the space on the heap because of how that function is implemented.
> >
> I believe it does. Commit 45babd780f586eb8d0a93205d0998d6ce3f8396d
> (which was committed after the bug report), changed
> make_xaudio2_factory() to no longer return class factories with a zero
> reference count. That happens sometimes.
>
> Unfortunately, looking over the first couple of entries in the list,
> it seems likely most of them are similarly already fixed. If you have
> the time and inclination it would certainly be useful to go over that
> list to figure out which ones are already fixed and which ones aren't,
> but that would make this a bit more of a challenge than I had
> intended. Sorry about that.
>
> Still, bugzilla is not a bad place to look for things to fix. The
> "download" keyword should limit searches to bugs that can be
> reproduced with free downloads. We also have various small cleanup
> tasks like e.g. replacing HeapAlloc() usage with the heap_alloc()
> helper, or introducing usage of the ARRAY_SIZE macro. The "patches"
> page [1] and git log may have other examples.
>
> [1] https://source.winehq.org/patches/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20180321/fcd4ece7/attachment-0001.html>