<div dir="ltr"><div><div>I think the output I attached was misleading. Really I'm just not understanding the output that I'm getting from valgrind. Namely is seems like the memory leaks are happening outside of wine.<br></div>Should I even care if a memory leak happens in libfontconfig? Does a memory leak there imply that there is an error in Wine? <br></div><div><br></div><div>Also now that I'm playing with it more, I'm not even sure if valgrind is actually testing anything. I'll attach the log in case anyone can point me in the right direction<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 21, 2018 at 9:10 PM, Josh DuBois <span dir="ltr"><<a href="mailto:duboisj@codeweavers.com" target="_blank">duboisj@codeweavers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi Kieran, <br>
</p>
<p> Someone else on the list is likely to be better help, but in
case you're in a hurry and don't get a quick response: it looks to
me like libfontconfig lacks debug symbols (which makes sense, as
I'd not expect your copy in /usr/lib to have those). Do you have
debug symbols for the wine functions (and if not, are you sure
your wine object files include them)? <br>
</p>
<p> I don't use Valgrind often, but I would guess you might be able
to 1.) build fontconfig yourself, with debug symbols; and then 2.)
cause wine to use your debug version instead of the system one by
setting LD_LIBRARY_PATH or somesuch. However, I'd also expect
that the traces you most want to see are those from wine.<br>
</p>
Again, a wine hacker and more regular Valgrind user from the list
may easily have better advice. <br><div><div class="h5">
<br>
<div class="m_-5854428316485865578moz-cite-prefix">On 3/21/18 7:27 PM, Kieran Duggan
wrote:<br>
</div>
<blockquote type="cite">
<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_<wbr>memcheck-amd64-linux.so)<br>
==14135== by 0x96B50B9: ??? (in
/usr/lib/x86_64-linux-gnu/<wbr>libfontconfig.so.1.9.0)<br>
==14135== by 0x96B5829: ??? (in
/usr/lib/x86_64-linux-gnu/<wbr>libfontconfig.so.1.9.0)<br>
==14135== by 0x96B6D4A: ??? (in
/usr/lib/x86_64-linux-gnu/<wbr>libfontconfig.so.1.9.0)<br>
==14135== by 0x96BC19B: ??? (in
/usr/lib/x86_64-linux-gnu/<wbr>libfontconfig.so.1.9.0)<br>
==14135== by 0x98E3A9B: ??? (in
/lib/x86_64-linux-gnu/<wbr>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>On 19 March 2018 at 10:01, Kieran Duggan <<a href="mailto:kieranduggan15@gmail.com" target="_blank">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_ICla<wbr>ssFactory,
(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/patc<wbr>hes/</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_-5854428316485865578mimeAttachmentHeader"></fieldset>
<br>
<pre></pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>