valgrind results updated
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(a)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. -- Dmitry.
On Nov 8, 2007 6:46 PM, Dmitry Timoshkov <dmitry(a)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
participants (2)
-
Dan Kegel -
Dmitry Timoshkov