| Summary: | Suppression files containing the "..." wildcard are not always handled correctly | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Bart Van Assche <bart.vanassche+kde> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | njn, ntrrgc, pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | wanted3.6.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Bart Van Assche
2009-07-28 10:38:11 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. 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
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.
|