Bug 480739 - heaptrack_gui crashes on analysing recorded trace
Summary: heaptrack_gui crashes on analysing recorded trace
Status: REPORTED
Alias: None
Product: Heaptrack
Classification: Applications
Component: general (show other bugs)
Version: 1.5.0
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Milian Wolff
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-02 16:05 UTC by Arvid Norlander
Modified: 2024-03-13 14:35 UTC (History)
0 users

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


Attachments
heaptrack_gdb_session.txt (138.70 KB, text/plain)
2024-02-02 16:05 UTC, Arvid Norlander
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Norlander 2024-02-02 16:05:37 UTC
Created attachment 165476 [details]
heaptrack_gdb_session.txt

SUMMARY
This happens both on 1.3.0 (packaged by ubuntu 22.04) as well as latest git master (claims to be 1.5.80, commit 1a849114c6c2269725fd137ff4114d7a1b6aef9e). The below gdb session is from latest git.

STEPS TO REPRODUCE
1.  Run heaptrack on proprietary program (sorry, I don't seem to be able to reproduce it on a trivial program): "heaptrack -r -o "%p.heaptrack" program --flags"
3. After 60 seconds, stop program from running (the program doesn't have a built in exit feature, it is normally cross compiled and run as the only program on an embedded linux system).
4. Run heaptrack_gui on resulting file
5. heaptrack_gui prints a bunch of errors and warnings, then crashes

OBSERVED RESULT
I have attached the full GDB session as a file as as it was rather long.  Here is some of the most pertinent info for searchability though:

failed to parse line: x 4c /home/USER/workspace/GIT_REPO/build/native/Debug/SUB_PROJECT/Main/PROGRAM_NAME
failed to parse line: m 1 -
failed to parse line: m 1 x 5595e3761000 0 16e9c2d0 16e9db80 72ed19
failed to parse line: m f linux-vdso.so.1 7ffc2b651000 0 10ab
failed to parse line: m 2a /usr/lib/heaptrack/libheaptrack_preload.so 7f3f324bb000 0 2a00 3000 5a0d 9000 186c bcf8 ad0
failed to parse line: m 28 /lib/x86_64-linux-gnu/libQt5Widgets.so.5 7f3f31c00000 0 14d348 14e000 3ddb09 52c000 162690 68f738 31710
failed to parse line: m 24 /lib/x86_64-linux-gnu/libQt5Gui.so.5 7f3f31400000 0 e1520 e2000 4de5a5 5c1000 faf9c 6bd960 1f6b8
failed to parse line: m 25 /lib/x86_64-linux-gnu/libQt5Core.so.5 7f3f30e00000 0 8dfb8 8e000 30eb61 39d000 1af831 54dd90 10ff0
failed to parse line: m 79 /home/USER/workspace/GIT_REPO/build/native/Debug/external/opcua/sdk/src/uaserver/uaservercpp/uamodule/libuamoduled.so 7f3f32387000 0 1047a8 1065b0 6adc
[...]
allocation index out of bounds: 4, maximum is: 0
allocation index out of bounds: 252, maximum is: 0
allocation index out of bounds: 504, maximum is: 0
allocation index out of bounds: 504, maximum is: 0
allocation index out of bounds: 2032, maximum is: 0
allocation index out of bounds: 1008, maximum is: 0
allocation index out of bounds: 1008, maximum is: 0
allocation index out of bounds: 32, maximum is: 0
allocation index out of bounds: 32, maximum is: 0
allocation index out of bounds: 16384, maximum is: 0
allocation index out of bounds: 32, maximum is: 0
allocation index out of bounds: 32, maximum is: 0
allocation index out of bounds: 56, maximum is: 0
allocation index out of bounds: 32, maximum is: 0
allocation index out of bounds: 64, maximum is: 0
[New Thread 0x7ffeb27fc640 (LWP 2157133)]

Thread 41 "GlobalQueue[01]" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff3bfff640 (LWP 2157101)]
0x0000555555608a74 in AccumulatedTraceData::read (this=0x7fff34004af0, in=..., pass=AccumulatedTraceData::FirstPass, isReparsing=false) at /home/USER/tooling/heaptrack/src/analyze/accumulatedtracedata.cpp:387
387	           totalCost.leaked -= info.size;
(gdb) bt
#0  0x0000555555608a74 in AccumulatedTraceData::read (this=0x7fff34004af0, in=..., pass=AccumulatedTraceData::FirstPass, isReparsing=false)
    at /home/USER/tooling/heaptrack/src/analyze/accumulatedtracedata.cpp:387
#1  0x00005555556074fc in AccumulatedTraceData::read (this=0x7fff34004af0, inputFile="/home/USER/workspace/GIT_REPO/build/sim/CONFIGURATION/PROGRAM_NAME-heaptrack.raw.zst", 
    pass=AccumulatedTraceData::FirstPass, isReparsing=false) at /home/USER/tooling/heaptrack/src/analyze/accumulatedtracedata.cpp:178
#2  0x00005555556071a4 in AccumulatedTraceData::read (this=0x7fff34004af0, inputFile="/home/USER/workspace/GIT_REPO/build/sim/CONFIGURATION/PROGRAM_NAME-heaptrack.raw.zst", 
    isReparsing=false) at /home/USER/tooling/heaptrack/src/analyze/accumulatedtracedata.cpp:146
#3  0x00005555555dd7d8 in operator() (__closure=0x555555e6f050) at /home/USER/tooling/heaptrack/src/analyze/gui/parser.cpp:689
#4  0x00005555555e96de in ThreadWeaver::Lambda<Parser::parseImpl(const QString&, const QString&, const FilterParameters&, Parser::StopAfter)::<lambda()> >::run(ThreadWeaver::JobPointer, ThreadWeaver::Thread *) (this=0x555555e6f040) at /usr/include/KF5/ThreadWeaver/threadweaver/lambda.h:30
#5  0x00007ffff789cb8d in ThreadWeaver::Executor::run(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x00007ffff789da74 in ThreadWeaver::Job::execute(QSharedPointer<ThreadWeaver::JobInterface> const&, ThreadWeaver::Thread*) () from /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x00007ffff78a21d6 in ThreadWeaver::Thread::run() () from /lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x00007ffff62ccca1 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007ffff5a94ac3 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442
#10 0x00007ffff5b26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) print totalCost
$1 = {allocations = 0, temporary = 0, leaked = 0, peak = 0}
(gdb) print info
$2 = (const AllocationInfo &) <error reading variable: Cannot access memory at address 0xfae189900>
(gdb) Unable to find file for pid 2156393 expected at "kcrash-metadata/2156393.ini"
The X11 connection broke (error 1). Did the X11 server die?
QSocketNotifier: Invalid socket 31 and type 'Read', disabling...
[1]  + exit 1     bin/heaptrack_gui 

$3 = (const AllocationInfo &) <error reading variable: Cannot access memory at address 0xfae189900>
(gdb) info locals
[...]

EXPECTED RESULT
It shouldn't crash? If the file is corrupt it should probably error out rather than crash.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Ubuntu 22.04
KDE Plasma Version:  KDE Plasma 5.27.10
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.3
Running on X11.

ADDITIONAL INFORMATION

So, I tried to provide you with the information anonymised file, but:

$ tools/anonymize 2161909.heaptrack.raw.zst bug_report_data.gz
gzip: 2161909.heaptrack.raw.zst: not in gzip format
# Well that doesn't seem to work...
$ zstdcat 2161909.heaptrack.raw.zst > tmp                           
09.heaptrack.raw.zst : Read error (39) : premature end 
# Hm... Possibly related?

Then I ran the anonymisation tool on that converted tmp file, but unfortunately it still leave paths and files names in it. So I cannot upload it as is. If you know of a way to anonymise this properly, or if there is anything I can do to help debug this, please let me know!
Comment 1 Arvid Norlander 2024-02-02 16:09:22 UTC
By the way, if I attach to the program everything works fine. Unfortunately I want to investigate the memory usage during the startup phase of the program, so that is not very useful to me.
Comment 2 Arvid Norlander 2024-02-05 08:36:13 UTC
As a workaround for anyone else who runs into this issue: You can capture a trace with https://github.com/koute/bytehound then export that trace to a heaptrack trace, which can then be loaded into the heaptrack_gui without crashing.
Comment 3 Milian Wolff 2024-02-12 19:28:09 UTC
can you either send me the original heaptrack file you analyze to trigger the crash (to my email address), or run it through the `heaptrack/tools/anonymize` tool and then send it to me?

that way I can better figure out what's going wrong
Comment 4 Milian Wolff 2024-02-12 19:35:46 UTC
oh I now see your attempt at using the tool. it seems to assume .gz input - can you replace the zcat with zstdcat and rerun?

also: you cannot directly analyze a raw trace, you first need to interpret that with heaptrack_interpret
Comment 5 Milian Wolff 2024-02-12 19:36:34 UTC
looks like you are misusing the tool (i.e. my hunch: you are missing a heaptrack_interpret call, or just remove the `-r` flag)
Comment 6 Arvid Norlander 2024-02-13 09:17:38 UTC
Thanks for your feedback. I'll take a look later today or tomorrow.
Comment 7 Bug Janitor Service 2024-02-28 03:46:34 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Arvid Norlander 2024-02-29 10:19:36 UTC
Sorry, I forgot about this (thanks bot for reminding me).

* I used the -r flag, the program runs in a context without access to GUI, so I need to split up the recording and analysis. But apparently there is also a --record-only flag. I don't quite understand the difference between these, --help is quite vague here to me as a user of heaptrack.
* I can't find any "heaptrack_interpret" in the heaptrack build directory. Please tell me more.

However, switching to using --record-only appears to work fine. Maybe the documentation in --help should make it more clear?
Comment 9 Milian Wolff 2024-03-13 14:35:22 UTC
sure, I can try to improve the documentation.

but I guess the real question is: what problem did you have when you didn't pass that along? worst case it will fail to launch the `heaptrack_gui` after analysis is done, but recording will work fine. so I guess the real thing to do here is to somehow detect whether we can launch a GUI and if not, then don't try to launch heaptrack_gui automatically?