Student preparing for GSoC

Thu Mar 22 01:15:03 CDT 2018

On 03/21/2018 08:58 PM, Kieran Duggan wrote:
> 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.
> Should I even care if a memory leak happens in libfontconfig? Does a memory
> leak there imply that there is an error in Wine?
> 
> 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
> 
> On Wed, Mar 21, 2018 at 9:10 PM, Josh DuBois <duboisj at codeweavers.com>
> wrote:
> 
>> Hi Kieran,
>>
>>   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)?
>>
>>   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.
>>   Again, a wine hacker and more regular Valgrind user from the list may
>> easily have better advice.
>>
>> On 3/21/18 7:27 PM, Kieran Duggan wrote:
>>
>> 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/

Hi Kieran,

If you haven't already, have a look at
https://github.com/austin987/wine-valgrind-scripts and
https://wiki.winehq.org/WineAndValgrind.

To run the full test suite, I use valgrind-full.sh. To just run a single
test, I do:
# terminal 1:
$ ~/wine-valgrind/wine start /min notepad

# terminal 2
. ~/src/wine-valgrind-scripts/vg-wrapper.sh
cd ~/wine-valgrind/dlls/advapi32/tests
make service.ok

The wine-valgrind-scripts repo has suppressions for fontconfig, etc.
Note that you can ignore known wine issues, so if you do that, make sure
to comment out its suppression!
-- 
-Austin
GPG: 267B CC1F 053F 0749 (expires 2021/02/18)