| Summary: | Symbols with length>200 in suppression files are ignored | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | eguillot |
| Component: | memcheck | Assignee: | Nicholas Nethercote <njn> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dank, njn |
| Priority: | NOR | ||
| Version First Reported In: | 3.4.1 | ||
| Target Milestone: | blocking3.5.0 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
simple program to reproduce the problem
Simple patch to raise limit by factor of ten. Seems to work. |
||
This cost me an hour today. Please, can we fix it for 3.5? Chrome routinely generates symbols with length ~ 330. For example: fun:_ZN3WTF9HashTableINS_6RefPtrIN7WebCore16AtomicStringImplEEESt4pairIS4_NS2_17CounterDirectivesEENS_18PairFirstExtractorIS7_EENS_7PtrHashIS4_EENS_14PairHashTraitsINS_10HashTraitsIS4_EENSD_IS6_EEEESE_E3addIPS3_S6_NS_29RefPtrHashMapRawKeyTranslatorISJ_S7_SG_SB_EEEES5_INS_17HashTableIteratorIS4_S7_S9_SB_SG_SE_EEbERKT_RKT0_ This is typical of many templated c++ programs. At the very least, please raise change N_BUF to 2000. Dan, it's listed as "blocking3.5.0" :) Sorry it cost you time. Created attachment 35174 [details]
Simple patch to raise limit by factor of ten. Seems to work.
Here's what I'm using now.
It's probably worth doing dynamically... we have enough hard-coded limits in Valgrind, there's no good reason for having one here, and someone will soon enough have a boost library involving a 10,000 character function name I'm sure! Sure. (I just didn't have time to code it... trying to keep the chrome valgrind buildbots green is like trying to hold back the tide :-) Fixed in r10581. It uses dynamic memory allocation now so in theory there's no upper limit to the symbol size, but in practice I bomb out if it's over 100,000 chars, just as a sanity check. |
Created attachment 31998 [details] simple program to reproduce the problem Hello, There is a limitation with symbol length in suppression files used by memcheck: If we have a memory error (or leak) that contains in its stack a symbol whose length is over 200 characters, the error is well detected, and valgrind manage to generate a valid suppression pattern. When using this pattern in an suppression file, the result is that the error is not matched against the pattern given in the file. It seems to be due to the "# define N_BUF 200" in method load_one_suppressions_file of m_errormgr.c Even if a limitation is kept (maybe size of buffer used for symbol storage can be dynamically calculated), the value for N_BUF should increased since the extensive usage of imbricated namespaces leads to huge symbols... In case we still reach the limit, a better handling of this limitation would be one of the following: - the adding of an error when trying to use suppression files with symbols > N_BUF characters (and then the user would have to specify some wildchars on the faulty line). - the adding of the same limitation on the symbol get from the execution of the program: with that, memcheck will consider that the pattern match if the N_BUF first characters are identical. Problem is that this solution can hide errors... Best regards