Summary: | Assertion failed "szB >= CACHE_ENTRY_SIZE" on m_debuginfo/image.c:517 | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Pedro Ferreira <arkangath> |
Component: | memcheck | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kde, mkg |
Priority: | NOR | ||
Version: | 3.13.0 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Pedro Ferreira
2017-10-05 07:37:35 UTC
Just prior to the crash, the last log message was: --15349-- Reading syms from /usr/lib64/libQt5Qml.so.5.7.1 --15349-- Considering /usr/lib/debug/usr/lib64/libQt5Qml.so.5.7.1.debug .. --15349-- .. CRC is valid Would attaching the debug symbols file help? I can't imagine how this failed. Can you still reproduce it? Despite my attempts, I am no longer able to trigger this. I do not recall what bug I was looking at when I stumbled onto this, and thus can't retrace my steps. Also, Gentoo has upgraded GCC since this was originally reported, so that might have had an effect on this as well. I was confident I had saved the debugging symbols file somewhere in case it would be required, but can't find it. *sigh* I suppose I am unable to provide you with additional information at present :( We are able to consistently reproduce this with Valgrind-3.15.0-608cb11914-20190413 (Different application, not kwrite) In the failure, the values are as such: szB=424 CACHE_ENTRY_SIZE=8192 We found that the assertion is no longer hit when we converted our application from compressed to uncompressed debug symbols. This seems to be a logic bug in the realloc_CEnt function that was never adjusted for compressed symbol support. alloc_CEnt has this logic: if (fromC) { // szB can be arbitrary } else { vg_assert(szB == CACHE_ENTRY_SIZE); } However realloc_CEnt does not have such a fromC argument and unconditionally checks vg_assert(szB >= CACHE_ENTRY_SIZE); Shouldn't these simply be aligned in behaviour? Unfortunately I can't share any examples, but I would greatly appreciate if someone could check my logic and consider a patch based on that. I think it requires a rather large binary with lots of debug symbols, as the cache re-uses compressed entries last, and that is when this bug happens. I can confirm that something trivial like e.g. below fixes it: --- a/coregrind/m_debuginfo/image.c +++ b/coregrind/m_debuginfo/image.c @@ -509,10 +509,10 @@ static UInt alloc_CEnt ( DiImage* img, SizeT szB, Bool fromC ) return entNo; } -static void realloc_CEnt ( DiImage* img, UInt entNo, SizeT szB ) +static void realloc_CEnt ( DiImage* img, UInt entNo, SizeT szB, Bool fromC ) { vg_assert(img != NULL); - vg_assert(szB >= CACHE_ENTRY_SIZE); + vg_assert(fromC || szB >= CACHE_ENTRY_SIZE); vg_assert(is_sane_CEnt("realloc_CEnt-pre", img, entNo)); img->ces[entNo] = ML_(dinfo_realloc)("di.realloc_CEnt.1", img->ces[entNo], @@ -768,7 +768,7 @@ static UChar get_slowcase ( DiImage* img, DiOffT off ) } vg_assert(i >= 0 && i < CACHE_N_ENTRIES); - realloc_CEnt(img, i, size); + realloc_CEnt(img, i, size, /*fromC?*/cslc != NULL); img->ces[i]->size = size; img->ces[i]->used = 0; if (cslc == NULL) { Committed, 3542be5bdc706b1a7d5d080ea01e81d4791e20b4. Thank you for the patch and the analysis. |