|
From: Dennis L. <pla...@gm...> - 2004-10-13 21:04:09
|
Hi people,
Im using valgrind from cvs, and noticed that in a few cases, something from
C++ is not demangled by valgrind. Do I need to tell valgrind something else
? Most things are demangled correctly.
Im using gcc 3.3.3 on a SuSE machine.
This is the output by valgrind :
by 0x1B96B3D7:
_ZNSt8_Rb_treeIPKcSt4pairIKS1_SsESt10_Select1stIS4_EN5iwear12cstring_lessESaIS4_EE12insert_equalISt17_Rb_tree_iteratorIS4_RS4_PS4_EEEvT_SG_
(stl_tree.h:1150)
by 0x1B96A3A8:
_ZNSt8multimapIPKcSsN5iwear12cstring_lessESaISt4pairIKS1_SsEEE6insertISt17_Rb_tree_iteratorIS6_RS6_PS6_EEEvT_SE_
(stl_multimap.h:363)
The multimap there is declared as following :
multimap<const char *, string, iwear::cstring_less>
while the insert operation done on it is this :
its insert(iterator,iterator) function
Another not demangled name is :
by 0x1B986722: _GLOBAL__I__ZN5iwear3uid6wehaveE (stl_set.h:100)
which is declared as following :
class uid
{
static set<iwear::uid*,deref_less<iwear::uid*> > wehave;
}
any hints ?
greets
Dennis
Carpe quod tibi datum est
|
|
From: Bryan O'S. <bo...@se...> - 2004-10-13 23:16:05
|
On Wed, 2004-10-13 at 23:04 +0200, Dennis Lubert wrote: > _ZNSt8_Rb_treeIPKcSt4pairIKS1_SsESt10_Select1stIS4_EN5iwear12cstring_lessESaIS4_EE12insert_equalISt17_Rb_tree_iteratorIS4_RS4_PS4_EEEvT_SG_ Maybe valgrind is passing an insufficiently large buffer to cplus_demangle? Using c++filt, this symbol expands to 1418 bytes. <b |
|
From: Madhu M K. <mm...@ya...> - 2004-10-13 23:52:39
|
Hmm: On Wed, 2004-10-13 at 16:15, Bryan O'Sullivan wrote: > On Wed, 2004-10-13 at 23:04 +0200, Dennis Lubert wrote: > > _ZNSt8_Rb_treeIPKcSt4pairIKS1_SsESt10_Select1stIS4_EN5iwear12cstring_lessESaIS4_EE12insert_equalISt17_Rb_tree_iteratorIS4_RS4_PS4_EEEvT_SG_ > > Maybe valgrind is passing an insufficiently large buffer to > cplus_demangle? Using c++filt, this symbol expands to 1418 bytes. > Not sure if that is the cause as frequently I've had demangled entries cut off midway. Which is sort of a pet peeve of mine - I've had a bunch of times when I been forced to rebuild valgrind for different users who cant use the "default" build since the setting in question is far far too conservative (IMHO). coregrind/core.h: 124: /* Max length of a text fragment used to construct error messages. */ 125: #define M_VG_ERRTXT 512 Perhaps someone can answer to this question, but is there a reason why that shouldn't be something on the order of 2048? I did not believe this was "a bug" since users could work around it by rebuilding valgrind, but I can open one up...... Cheerio, M -- Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Bryan O'S. <bo...@se...> - 2004-10-14 05:21:03
|
On Wed, 2004-10-13 at 16:52 -0700, Madhu M Kurup wrote: > Not sure if that is the cause as frequently I've had demangled entries > cut off midway. > coregrind/core.h: > 124: /* Max length of a text fragment used to construct error messages. > */ > 125: #define M_VG_ERRTXT 512 > > Perhaps someone can answer to this question, but is there a reason why > that shouldn't be something on the order of 2048? Oh, dear. If 512 is causing truncation, then 2048 surely won't be enough. It's quite easy to generate C++ symbols that demangle to 8K in length. Many of those masochistic C++ "let's write everything as a heap of templates and optimise everything we don't need away at compile time" libraries are going to blow right past that. <b |
|
From: Nicholas N. <nj...@ca...> - 2004-10-18 15:59:12
|
On Wed, 13 Oct 2004, Bryan O'Sullivan wrote: >> 124: /* Max length of a text fragment used to construct error messages. >> */ >> 125: #define M_VG_ERRTXT 512 >> >> Perhaps someone can answer to this question, but is there a reason why >> that shouldn't be something on the order of 2048? > > Oh, dear. If 512 is causing truncation, then 2048 surely won't be > enough. It's quite easy to generate C++ symbols that demangle to 8K in > length. I've committed a change that increases it to 4096, which will be in the next release. It should be a clear improvement, even if it doesn't catch the really nasty cases. N |
|
From: Dennis L. <pla...@gm...> - 2004-10-18 16:25:27
|
At 17:58 18.10.2004, you wrote: >On Wed, 13 Oct 2004, Bryan O'Sullivan wrote: > >I've committed a change that increases it to 4096, which will be in the >next release. It should be a clear improvement, even if it doesn't catch >the really nasty cases. Nice! I think 4096 is enough, since if the demangled symbol is even bigger, noone will really try to understand it. But is it perhaps possible to add some kind of warning, if the symbol is not demangled ? Like add some (not demangled , symbol too big) to the output function then ? This would be great, so we can see if _GLOBAL__I__ZN5iwear3uid6wehaveE isn't demangled because of too few bufferspace too... greets Dennis Carpe quod tibi datum est |
|
From: Madhu M K. <mm...@ya...> - 2004-10-18 18:58:46
|
On Mon, 2004-10-18 at 09:26, Dennis Lubert wrote:
> >
> >I've committed a change that increases it to 4096, which will be in the
> >next release. It should be a clear improvement, even if it doesn't catch
> >the really nasty cases.
Thanks ... this should catch about 99% of the demangled names.
>
> Nice! I think 4096 is enough, since if the demangled symbol is even bigger,
> noone will really try to understand it. But is it perhaps possible to add
> some kind of warning, if the symbol is not demangled ? Like add some (not
> demangled , symbol too big) to the output function then ?
> This would be great, so we can see if _GLOBAL__I__ZN5iwear3uid6wehaveE
> isn't demangled because of too few bufferspace too...
Like I said before - I don't think the lack of demangling is due to a
lack of space - it's just that the demangling algo's parsing gets broken
due to g++ changes / magic / quantum mechanics / {take your pick}.
I would suggest that you try and find the raw mangled name and see if
why the parsing breaks down. Possibly open a bug for it.
Cheerio,
M
--
Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com
|