[
https://issues.apache.org/jira/browse/ARROW-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286400#comment-17286400
]
Maarten Breddels commented on ARROW-3016:
-----------------------------------------
I'd also recommend using perf with uprobes for this, especially for non-Python
programs this should work well, but might require the `-fno-omit-frame-pointer`
for compilation, or passing `--call-graph dwarf` to perf as mentioned above.
The output of perf-script is easy to parse and finding leaks should be possible
this way, but I wouldn't be surprised if there are a ton of tools out there
already (I know they exist for finding deadlocks).
For combining with Python, it could be useful to add support for mem
allocations in the `per4m` package so the leak information can be merged info
with VizTracer's output. Collecting Python stack traces of mem leaks should be
possible (i.e. not a visualization as with VizTracer), but would require some
extra steps/work.
I think in general, tooling like this should not be done in userland, because
you become blind to what is happening in the kernel. Getting deep stack traces
from perf that go into the kernel can be useful, especially with memory
allocations. One can even see the time spend on setting up pages and all and
this has given me ideas on looking into using huge pages.
> [C++] Add ability to enable call stack logging for each memory allocation
> -------------------------------------------------------------------------
>
> Key: ARROW-3016
> URL: https://issues.apache.org/jira/browse/ARROW-3016
> Project: Apache Arrow
> Issue Type: New Feature
> Components: C++
> Reporter: Wes McKinney
> Priority: Major
> Fix For: 4.0.0
>
>
> It is possible to gain programmatic access to the call stack in C/C++, e.g.
> https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/
> It would be valuable to have a debugging option to log the sizes of memory
> allocations as well as showing the call stack where that allocation is
> performed. In complex programs, this could help determine the origin of a
> memory leak
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
