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@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@gmail.com wrote:
On 19 March 2018 at 10:01, Kieran Duggan kieranduggan15@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.
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@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@gmail.com wrote:
On 19 March 2018 at 10:01, Kieran Duggan kieranduggan15@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.
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!
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@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@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@gmail.com
wrote:
On 19 March 2018 at 10:01, Kieran Duggan kieranduggan15@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.
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)
On Mar 22, 2018 22:42, "Kieran Duggan" kieranduggan15@gmail.com wrote:
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?
Many tests aren't safe to run in parallel, things may fail.
That makes sense
On Thu, Mar 22, 2018, 11:45 PM Austin English austinenglish@gmail.com wrote:
On Mar 22, 2018 22:42, "Kieran Duggan" kieranduggan15@gmail.com wrote:
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?
Many tests aren't safe to run in parallel, things may fail.
Would making the tests safe to run in parallel be a good proposal idea? Or is it too ambitious for a summer project. Running these tests in one process is painstaking on my FX-8350
On Thu, Mar 22, 2018 at 11:47 PM, Kieran Duggan kieranduggan15@gmail.com wrote:
That makes sense
On Thu, Mar 22, 2018, 11:45 PM Austin English austinenglish@gmail.com wrote:
On Mar 22, 2018 22:42, "Kieran Duggan" kieranduggan15@gmail.com wrote:
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?
Many tests aren't safe to run in parallel, things may fail.
On Mar 22, 2018 22:52, "Kieran Duggan" kieranduggan15@gmail.com wrote:
Would making the tests safe to run in parallel be a good proposal idea? Or is it too ambitious for a summer project. Running these tests in one process is painstaking on my FX-8350
On Thu, Mar 22, 2018 at 11:47 PM, Kieran Duggan kieranduggan15@gmail.com wrote:
That makes sense
On Thu, Mar 22, 2018, 11:45 PM Austin English austinenglish@gmail.com wrote:
On Mar 22, 2018 22:42, "Kieran Duggan" kieranduggan15@gmail.com wrote:
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?
Many tests aren't safe to run in parallel, things may fail.
Imo probably not a GSOC project, but I'm open to disagreement.
The full tests take about 20 minutes, but valgrind takes 10 hours (on my machine). I wouldn't recommend that to check on a single bug. Using the wrapper and suppression files should get you a setup close to mine for testing, however.
Am 23.03.2018 um 04:52 schrieb Kieran Duggan kieranduggan15@gmail.com:
Would making the tests safe to run in parallel be a good proposal idea? Or is it too ambitious for a summer project. Running these tests in one process is painstaking on my FX-8350
I agree with Austin that it is not a good gsoc project, largely because it is a mix of 'impossible' and 'trivial'.
Some tests can't be run in parallel because they change the screen resolution, e.g. ddraw, d3d8, d3d9, etc. Some user32 tests test handling of window focus loss and restore, which breaks if a separate test opens a window in a bad moment.
Dan Kegel once upon a time made a list of tests that can be parallelized.
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@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@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@gmail.com
wrote:
On 19 March 2018 at 10:01, Kieran Duggan kieranduggan15@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.
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)
On Sat, Mar 24, 2018 at 1:34 AM, Kieran Duggan kieranduggan15@gmail.com wrote:
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
Hi Kieran,
You've got it. Notice how the output is prefixed with the pid of the wine process; that's valgrind's output. The source code lines on the end of the line, like a backtrace.
So that output shows that there's a leak in atl100, allocated via heap.c's notify_alloc, then RtlAllocateHeap, then IOCS_Create, then AtlAxAttachControl).
Your task would be to find that leak, then fix it, i.e., free the memory where it should have been, but wasn't.
FYI, after running the tests, you may need to run 'rm service.ok', otherwise the test won't run (only if it succeeded beforehand).
-
Austin English -
Kieran Duggan -
Stefan Dösinger