While running massif it throws a few dozen errors at startup: ==21540== Massif, a space profiler for x86-linux. ==21540== Copyright (C) 2003, Nicholas Nethercote ==21540== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==21540== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" ==21540== For more details, rerun with: -v ==21540== @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" It then appears to run correctly. This is with a binary compiled using gcc 2.96 (stock RedHat 7.3) compiled with -g and dynamically linked with the Qt libraries.
Same problem here with binaries compiled with gcc 2.95 on Debian Woody. Frontend was memcheck. Rather seems like a problem in the core.
CVS commit by thughes: The fix for bug 85811 added decoding of many extra negative type numbers in stabs and also removed the expectation of a trailing semicolon after the type number as gcc didn't seem to be putting one in. It seems that older gcc's do add one however, so we now skip one if it is there. CCMAIL: 88703-done@bugs.kde.org M +6 -0 vg_stabs.c 1.16 --- valgrind/coregrind/vg_stabs.c #1.15:1.16 @@ -676,4 +676,10 @@ static SymType *stabtype_parser(SegInfo break; } + /* Different versions of gcc seem to disagree about whether a + negative type is followed by a semicolon or not, and the stabs + spec (susch as it is) is not clear either so we will skip a + semicolon if there is one. */ + if (*p == ';') + p++; break; }