I've updated http://kegel.com/wine/valgrind/ Today's results are at http://kegel.com/wine/valgrind/20071103/
The only difference from yesterday is I've added suppressions for the most common memory leaks, on the theory that it's easier to see the module-specific leaks that way.
(I haven't looked to see if they're false positives, so I named them todo* to remind us to look at them again later.)
As always, there are leaks and uninitialized memory references aplenty! Step right up, no waiting...
"Dan Kegel" dank@kegel.com wrote:
I've updated http://kegel.com/wine/valgrind/ Today's results are at http://kegel.com/wine/valgrind/20071103/
The only difference from yesterday is I've added suppressions for the most common memory leaks, on the theory that it's easier to see the module-specific leaks that way.
I looked at the vg-user32_win.txt warnings, and most of them are triggered by test_gettext() which intentionally passes an invalid memory address to SendMessage(WM_GETTEXT).
There is also one memry leak reported, but I couldn't figure out the reason of that one.
On Nov 8, 2007 6:46 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
I looked at the vg-user32_win.txt warnings, and most of them are triggered by test_gettext() which intentionally passes an invalid memory address to SendMessage(WM_GETTEXT).
OK, I'll add a suppression for that.
BTW tests/win.c seems pretty racy. It fails strangely with warn+heap and differently strangely under valgrind. Under Valgrind, I bet the test is just bad at running really slowly. No idea why it fails with warn+heap, which doesn't seem too slow.
There is also one memry leak reported, but I couldn't figure out the reason of that one.
I'm not so worried about those, a leak's not as bad as a wild pointer, and it's probably just a missing free or close or something in the test code. But thanks for looking. - Dan
-
Dan Kegel -
Dmitry Timoshkov