|
From: Dan K. <da...@ke...> - 2008-02-12 06:55:25
|
In December, I was seeing this assertion failure, but the stack traceback was poor (probably because I had a patched valgrind); see http://www.kegel.com/wine/valgrind/logs-2007-12-14/vg-winmm_wave-diff.txt With today's Valgrind from svn, unpatched, the assertion still's happening, but the stack traceback is much better. Here's the text: Memcheck: mc_leakcheck.c:698 (vgMemCheck_do_detect_memory_leaks): Assertion 'lc_shadows[i]->data + lc_shadows[i]->szB <= lc_shadows[i+1]->data' failed. at report_and_quit (m_libcassert.c:140) by vgPlain_assert_fail (m_libcassert.c:200) by vgMemCheck_do_detect_memory_leaks (mc_leakcheck.c:697) by mc_detect_memory_leaks (mc_main.c:4214) by mc_fini (mc_main.c:4904) by shutdown_actions_NORETURN (m_main.c:2025) by run_a_thread_NORETURN (syswrap-linux.c:144) sched status: running_tid=1 This is on Ubuntu Feisty, running the wine conformance test suite. Worth filing a bug for? - Dan |
|
From: Julian S. <js...@ac...> - 2008-02-12 10:13:31
|
> Worth filing a bug for? I'd say yes, considering it's happening in an unpatched valgrind. J |
|
From: Julian S. <js...@ac...> - 2008-02-12 23:55:18
|
On Tuesday 12 February 2008 11:10, Julian Seward wrote: > > Worth filing a bug for? > > I'd say yes, considering it's happening in an unpatched valgrind. It may or not be related to this: http://bugs.kde.org/show_bug.cgi?id=156065 J |
|
From: John R.
|
> Memcheck: mc_leakcheck.c:698 (vgMemCheck_do_detect_memory_leaks): > Assertion 'lc_shadows[i]->data + lc_shadows[i]->szB <= > lc_shadows[i+1]->data' failed. > at report_and_quit (m_libcassert.c:140) [snip] > by shutdown_actions_NORETURN (m_main.c:2025) > by run_a_thread_NORETURN (syswrap-linux.c:144) This is a classic "garbage collection" assertion. The error happened long ago and far away: one or more malloc/realloc/free was not seen, or there was some other error in the accounting for one or more blocks. To fix it you either need an oracle, or a way to check the assertion after every change in the accounting for blocks. It might be helpful to check the assertion at other times, too [such as: at every CALL and/or RETURN] just in case you do not realize all the places where the accounting could change. -- John Reiser, jreiser@BitWagon.com |