Student preparing for GSoC

Thu Mar 22 22:42:36 CDT 2018

Cool I didn't get the chance to take a look at it before. I'm using it now.
I noticed that the line:
time make -k test >> "$logfile" 2>&1 || true
doesn't use the -j option for make. I'm not sure if this is intentional,
but when I changed it to
time make -j"$(nproc)" -k test >> "$logfile" 2>&1 || true
it ran much faster. Thoughts? Am I just breaking something without
realizing it?

On Thu, Mar 22, 2018 at 2:15 AM, Austin English <austinenglish at gmail.com>
wrote:

> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20180322/eeefd692/attachment-0001.html>