<div dir="ltr"><div><div><div><div>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<br>==14135== 288 (256 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 166 of 278<br>==14135==    at 0x442EB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)<br>==14135==    by 0x96B50B9: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)<br>==14135==    by 0x96B5829: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)<br>==14135==    by 0x96B6D4A: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)<br>==14135==    by 0x96BC19B: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0)<br>==14135==    by 0x98E3A9B: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.0)<br><br></div>but this isn't nearly as useful as the output I see on bugzilla, which includes function calls and such<br>I tried recompiling my build with valgrind installed on my computer<br> and checked to be sure that the make config was detected it with<br>grep VALGRIND include/config.h and I get <br><br></div>#define HAVE_VALGRIND_MEMCHECK_H 1<br>#define HAVE_VALGRIND_VALGRIND_H 1<br><br></div>so I don't think that is the problem.<br><br></div><div>It seems to me like valgrind is expecting there to be some flags or something for it to find but they aren't there.<br></div><div>Can anyone offer some assistance?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 19, 2018 at 5:51 AM, Henri Verbeet <span dir="ltr"><<a href="mailto:hverbeet@gmail.com" target="_blank">hverbeet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19 March 2018 at 10:01, Kieran Duggan <<a href="mailto:kieranduggan15@gmail.com">kieranduggan15@gmail.com</a>> wrote:<br>
> Yes that is very useful!<br>
> I took a look at the first one I saw on the list. It goes:<br>
><br>
> ==3551== 8 bytes in 1 blocks are definitely lost in loss record 63 of 766<br>
> ==3551==    at 0x7BC51061: notify_alloc (heap.c:254)<br>
> ==3551==    by 0x7BC5554F: RtlAllocateHeap (heap.c:1716)<br>
> ==3551==    by 0x5C85281: XAudio2Create (xaudio_dll.c:2159)<br>
> ==3551==    by 0x4A1B741: func_xaudio2 (xaudio2.c:1150)<br>
> ==3551==    by 0x4A1C74F: run_test (test.h:603)<br>
> ==3551==    by 0x4A1CBAD: main (test.h:687)<br>
> ==3551==<br>
><br>
> To fix it I looked at the XAudio2Create function and noticed that<br>
> IClassFactory *cf was assigned in the call<br>
> make_xaudio2_factory(&IID_<wbr>IClassFactory, (void**)&cf);<br>
> which contains<br>
> struct xaudio2_cf *ret = HeapAlloc(GetProcessHeap(), 0, sizeof(struct<br>
> xaudio2_cf));<br>
><br>
> Later in the code IClassFactory_Release(cf); is used, but this wouldn't free<br>
> up the space on the heap because of how that function is implemented.<br>
><br>
</span>I believe it does. Commit 45babd780f586eb8d0a93205d0998d<wbr>6ce3f8396d<br>
(which was committed after the bug report), changed<br>
make_xaudio2_factory() to no longer return class factories with a zero<br>
reference count. That happens sometimes.<br>
<br>
Unfortunately, looking over the first couple of entries in the list,<br>
it seems likely most of them are similarly already fixed. If you have<br>
the time and inclination it would certainly be useful to go over that<br>
list to figure out which ones are already fixed and which ones aren't,<br>
but that would make this a bit more of a challenge than I had<br>
intended. Sorry about that.<br>
<br>
Still, bugzilla is not a bad place to look for things to fix. The<br>
"download" keyword should limit searches to bugs that can be<br>
reproduced with free downloads. We also have various small cleanup<br>
tasks like e.g. replacing HeapAlloc() usage with the heap_alloc()<br>
helper, or introducing usage of the ARRAY_SIZE macro. The "patches"<br>
page [1] and git log may have other examples.<br>
<br>
[1] <a href="https://source.winehq.org/patches/" rel="noreferrer" target="_blank">https://source.winehq.org/<wbr>patches/</a><br>
</blockquote></div><br></div>