DynamoRIO / DynamoRIO/drmemory

mod+offs suppression doesn't work on tests/malloc, and adds bogus callstack from symbol suppression

Open
#145 0 comments 0 reactions 0 assignees View on GitHub
Migrated Priority-Low
Dominant language
C
Stars
2.7k
Forks
290
PR merge metrics
No merged PRs in 30d

Description

_From [derek.br...@gmail.com](https://code.google.com/u/117968039472581148324/) on December 10, 2010 17:58:00_

PR 464809

It doesn't work on tests/malloc b/c the suppress.txt is missing the 2nd
"not in a module" frame, yet that frame is present in the original error
that suppress.txt was generated from and in the same error in the next run:

added to suppression table " "

on_suppression_list: looking up " "
on_suppression_list: looking up " "

Also, for the symbol callstack, why is drmem adding the final "not in a module"?

suppression file line: "# This call stack is the symbol based version of the one above"
suppression file line: "UNADDRESSABLE ACCESS"
suppression file line: "malloc!main"
suppression file line: "libc.so.6!__libc_start_main"
suppression file line: "malloc!_start"
suppression file line: "malloc!__libc_csu_init"
suppression file line: " "
suppression file line: ""

added to suppression table " "

```
Went ahead and fixed part of PR 464809 since it was an easy fix:
* Include address of 0 in suppression callstacks

Results: memory usage of -check_leaks is about 1/8 of what it was.
But we're still using a noticeable amount on a many-malloc app:
at init point about 43MB for stored callstacks (410K outstanding mallocs).
We'll want to share identical callstacks to cut that (=> PR 465174).
```

I fixed first problem, the missing frames, then just those frames are read by libdrmemory.so and used for suppression, which is incorrect because all mod!func type suppression call stacks should be ignored by libdrmemory.so (mod!func suppression info is for postprocess.pl).

As frames are no longer printed by default, this isn't an issue. However, if the user explicitly asks for showing non module frames in error reports and uses them in suppression call stacks, then frames should be ignored for mod!func type suppression info and not for mod+offs type. Otherwise, in the rare case that the top-most frame of an error has frame, it might be suppressed incorrectly.

Lowering priority as the default is what is relevant in most scenarios.

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=145_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.