| Summary: | Extend existing report (from embedded device) by stacktrace info on different machine? | ||
|---|---|---|---|
| Product: | [Applications] Heaptrack | Reporter: | Lukáš Karas <lukas.karas> |
| Component: | general | Assignee: | Milian Wolff <mail> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | orehovpasha |
| Priority: | NOR | ||
| Version First Reported In: | 1.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Lukáš Karas
2019-09-20 00:45:15 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. :) 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. 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. |