Feature: Support reports on demand #12
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The tool currently only produces reports on a clean exit from the analyzed program, which is not always achievable (daemons, programs crashing, etc.). An "on demand" report requested from within the application itself has proven useful in debugging scenarios, e.g. by attaching a debugger to the analyzed program and then just call a routine from there for producing a `heapusage` report. This way, extend `heapusage` with a public API, currently only having a `hu_report()` function for generating a `heapusage` report as done from `log_summary()`. The new API files are `huapi.h` and `huapi.cpp`. The header file first gets installed in the standard include dir so other SW modules can use it. The source file is added to the library's link step. The `log_summary()` call for generating the report from `hu_report()` is wrapped by a new `log_summary_safe()` function, so that `heapusage` analysis is temporarily disabled when actually calling `log_summary()`, otherwise `log_summary()` itself, which does memory allocations, would interfere with the analysis. This problem didn't exist before, because `log_summary()` was only being called from the exit handler, which also disables the analysis before calling `log_summary()`. Also add an internal global `log_message()` function, useful for logging generic messages into the `heapusage` log. Update `README.md` with this new usage possibility. Signed-off-by: Ricardo Silva <[email protected]>
The `log_summary()` function is causing problems when being called multiple times in the same run, i.e. if called multiple process while the program being analyzed is running. The observed problems are: * The `size` and `count` fields for leaked blocks for the same callstack are accumulating between calls, messing with the statistics. * If there are previous calls to `log_summary()` from e.g. on demand report requests done by using `hu_report()`, the last call done when the program exits (from `hu_fini()`), causes crashes (`SIGABRT` and `SIGSEGV` have been observed). This all happens because the `allocations_by_callstack` map is being used as `static`. This doesn't really seem to be needed or that useful, since the size of the map is really small (measured as 24 bytes), so no real memory savings by declaring it as static. There's also no observed impact on the `log_summary()` performance by removing the `static` attribute. This way, let `allocations_by_callstack` be allocated from the stack and restarted on every `log_summary()` call, hence avoiding the mentioned problems. Signed-off-by: Ricardo Silva <[email protected]>
The tool currently only produces reports on a clean exit from the analyzed program, which is not always achievable (daemons, programs crashing, etc.), and also using `hu_report()` as an API, which might also not be doable in all scenarios (e.g. no source code for the analyzed program). An "on demand" report requested from "the outside world" has proven very useful in some debugging scenarios. Having a signal that could be sent to the analyzed program (e.g. sent from a shell) and have the `heapusage` tool catch it and produce a report in response is very helpful. This way, install a signal handler for the `SIGUSR1` and `SIGUSR2` user defined signals and, for `SIGUSR1` trigger a report using `log_summary_safe()`, just like the `hu_report()` API does. Leave the `SIGUSR2` available for other future requests. Update `README.md` with this new usage possibility. Signed-off-by: Ricardo Silva <[email protected]>
|
Hi @rjpdasilva - thanks for contributing 👍 Btw - do not worry about the failing macOS check for the PR, I suspect it's some general issue caused by changes to Github CI runners, so it's something I will address separately from this PR. |
|
Hi @rjpdasilva - I've raised a PR for updating your fork with latest heapusage master so it will be easier for me to test it out. |
|
Hi @d99kris,
If you prefer I can raise a new PR rebased on your latest |
|
Sure that's fine too, either works for me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The tool currently only produces reports on a clean exit from the analyzed program, which is not always achievable (daemons, programs crashing, etc.). An "on demand" report requested programmatically from within the application itself or from the "outside world" via a signal, has proven quite useful in multiple debugging scenarios.
Commit 4acca12 allows requesting reports via a new API function named
hu_report().Commit 2de0126 allows requesting reports via
SIGUSR1Linux signals.Commit 3d60e08 fixes
log_summary()so that can be called multiple times while the program is running.