Bug 412098 - Extend existing report (from embedded device) by stacktrace info on different machine?
Summary: Extend existing report (from embedded device) by stacktrace info on different...
Status: CONFIRMED
Alias: None
Product: Heaptrack
Classification: Applications
Component: general (show other bugs)
Version: 1.1.0
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Milian Wolff
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-20 00:45 UTC by Lukáš Karas
Modified: 2021-02-19 09:53 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lukáš Karas 2019-09-20 00:45:15 UTC
Hi. 

It is possible to extend existing heaptrack report by stacktrace information on different machine?

I want to collect heap usage report on embedded device. On this device hasn't enough space for installing debug symbols for all libraries that are used by the process. Because of that, generated report contains many "<unresolved function>" placeholders. In our (yocto based) SDK, we are able to prepare sysroot with all libraries and its debug symbols. We are using it for coredump analysis. So I believe that it should be possible even for heaptrack...

If yes, can you provide me so hint, or link to documentation?

If there is not such option (yet), can I ask you for this feature? Or at least describe me the building blocks, I can try to implement this :-)
Comment 1 Pash 2021-02-19 05:04:01 UTC
The heavy heaptrack_interpret is separate process. You can try to move it to another host via DUMP_HEAPTRACK_OUTPUT env. But problems with debug symbols loading should be. You can create chroot with target's libs and run heaptrack_interpret where. May be. Sorry. :)
Comment 2 Milian Wolff 2021-02-19 09:03:43 UTC
I'm totally on board with this request - but I simply couldn't find the time/motivation yet to work on it.

Basically the way it should work is that we take the raw data that would usually get fed into heaptrack_interpret and instead compress it with zstd, then send it to a network socket which then gets uncompressed on another machine and fed into heaptrack_interpret.

Alternatively, we could just store that raw compressed data to a file and then interpret it afterwards on a different machine.

Furthermore, we then also need to define the sysroot and search paths similar to what we can do with hotspot too e.g.
Comment 3 Pash 2021-02-19 09:53:26 UTC
you can look to https://git.tizen.org/cgit/sdk/tools/heaptrack/commit/?id=76e5908d8abb7f45395463b5b04fb46a6caf3963 for network socket usage.

> I simply couldn't find the time/motivation yet to work on it.
It's open source, baby. Do it yourself or or fund someone or shut up.