Bug 201742 - Suppression files containing the "..." wildcard are not always handled correctly
Summary: Suppression files containing the "..." wildcard are not always handled correctly
Status: CONFIRMED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (other bugs)
Version First Reported In: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: wanted3.6.0
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-28 10:38 UTC by Bart Van Assche
Modified: 2025-05-23 19:57 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bart Van Assche 2009-07-28 10:38:11 UTC
Version:           3.5.0.svn (using KDE 4.1.3)
Compiler:          gcc 4.3.2 gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)
OS:                Linux
Installed from:    SuSE RPMs

(found this through source reading)

The code for reading suppression files reads as many stack frames from each suppression pattern as specified in the --num-callers command-line argument. (The value of this command-line argument is stored in VG_(clo_backtrace_size) and defaults to 12.) When e.g. specifying --num-callers=2 and when Valgrind encounters a suppression pattern with the three stackframes "...", "fun:A" and "fun:B", only "..." and "fun:A" will be read from the file containing the suppression pattern. As a result, the suppression pattern will not only match the backtrace "fun:A", "fun:B" (as expected) but will also match with the backtrace "fun:A", "fun:C" (not expected). I consider this as a bug.
Comment 1 Nicholas Nethercote 2009-07-30 02:51:41 UTC
This relates to bug 199468.  Suppression matching is quite tricky when the number of stack entries in an error is less than the number in the suppression.  We should clarify this.
Comment 2 Alicia Boya García (ntrrgc) 2025-05-23 18:05:43 UTC
I would suggest renaming the title of this bug to "Expectation rules are silently cropped to --num-callers", as this bug applies as well to suppressions rules that don't contain "...".

Recently I've been in a goose chase in GStreamer as a certain leak was being reported but only in certain configurations.

When running valgrind with the default arguments plus some suppression files I found a leak that should be reported wasn't being reported. Eventually I tracked it down to an old suppression rule that looked like this:

{
   <One time init in ALSA>
   Memcheck:Leak
   fun:calloc
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:/usr/lib/libasound.so.*
   fun:snd_config_searcha_hooks
   fun:snd_config_searchva_hooks
   obj:/usr/lib/libasound.so.*
   fun:snd_config_search_definition
   obj:/usr/lib/libasound.so.*
   fun:gst_alsa_device_property_probe_get_values
}

`--num-callers` defaults to 12, which caused that rule to be effectively cropped, functionally becoming this:

{
   <One time init in ALSA>
   Memcheck:Leak
   fun:calloc
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
}

In other words, any call to calloc() with a stack trace that has 12 or more frames is suppressed for memcheck, which is very much not what the original rule was intended to filter.

Here is a minimal repro without GStreamer:

$ cat > leak.c
#include <stdlib.h>
void* do_allocation() {
    return malloc(256);
}
void func1() { do_allocation(); }
void func2() { func1(); }
void func3() { func2(); }
void func4() { func3(); }
void func5() { func4(); }
void func6() { func5(); }
void func7() { func6(); }
void func8() { func7(); }
void func9() { func8(); }
void func10() { func9(); }
void func11() { func10(); }
void func12() { func11(); }
int main() {
    func12();
}

$ cat > a.supp
{
   <supression that matches what it shouldn't>
   Memcheck:Leak
   fun:malloc
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   obj:*
   fun:non_existing_function
}

$ gcc leak.c
$ valgrind --leak-check=full --suppressions=a.supp ./a.out
[...]
==1539875== LEAK SUMMARY:
==1539875==    definitely lost: 0 bytes in 0 blocks
==1539875==    indirectly lost: 0 bytes in 0 blocks
==1539875==      possibly lost: 0 bytes in 0 blocks
==1539875==    still reachable: 0 bytes in 0 blocks
==1539875==         suppressed: 256 bytes in 1 blocks
Comment 3 Paul Floyd 2025-05-23 19:57:02 UTC
If my awk skills are right then the sizes of the default suppressions vary like


 awk 'BEGIN{in_stack=0}/^{/{count=0;in_stack=1;next}/^}/{print count;in_stack=0;next}{if (in_stack==1) count=count+1;}' *.supp | sort -un
3
4
5
6
7
8
9
10

There are 3 non-stack lines, so the stack sizes are from 1 to 7. That's less than the default number of callers which is 12.

Does this also mean that users that lower --num-callers= could also be affected? I see one xcb suppression that is probably a bit over-specific. Probably not much of an issue or we'd have heard more complaints by now.