Student preparing for GSoC

Sat Mar 24 01:34:16 CDT 2018

So I'm attempting to run individual tests now. What exactly should I do
after I "make service.ok"? I tried just running valgrind the way I would
expect to use it i.e.

valgrind --trace-children=yes --track-origins=yes --leak-check=full
--num-callers=20 --workaround-gcc296-bugs=yes --log-file="filename.log"
./wine /home/kduggan15/Documents/Wine/wine-valgrind/dlls/atl100/tests/
atl100_test-stripped.exe.so

I get

64 bytes in 1 blocks are definitely lost in loss record 1,250 of 2,380
==11711==    at 0x7BC46859: notify_alloc (heap.c:260)
==11711==    by 0x7BC49D56: RtlAllocateHeap (heap.c:1726)
==11711==    by 0x4D16D40: IOCS_Create (atl_ax.c:952)
==11711==    by 0x4D17572: AtlAxAttachControl (atl_ax.c:1156)
==11711==    by 0x4804025: ??? (in
/home/kduggan15/Documents/Wine/wine-valgrind/dlls/atl100/tests/
atl100_test-stripped.exe.so)

The issue being that the atl100_test-stripped.exe.so doesn't have any debug
symbols
Also I initially tried make service.ok and I just get something likemake
service is up to date or it just builds the tests without running valgrind.
If it does run valgrind, then I don't know where the log is going (and I
checked wine-valgrind/logs of course)

That's basically all I got. Sorry if these questions are a bit basic. I'm
just running into a few roadblocks and could use the assistance. I really
appreciate the help

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/20180324/3f592132/attachment-0001.html>