| Summary: | Application under heaptrack gets stuck | ||
|---|---|---|---|
| Product: | [Applications] Heaptrack | Reporter: | Vadim Peretokin <vperetokin> |
| Component: | general | Assignee: | Milian Wolff <mail> |
| Status: | REPORTED --- | ||
| Severity: | normal | ||
| 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
Vadim Peretokin
2019-07-22 14:39:40 UTC
It looks like a deadlock happens due to a 3rd party library we use (https://github.com/edbee/edbee-lib/issues/) when running under heaptrack: mudlet::mudlet() ERROR - Failed to directly load a translator for: "en_US" a translation to the specified language will not be available ^C Thread 1 "mudlet" received signal SIGINT, Interrupt. syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory. (gdb) bt #0 0x00007ffff358f839 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007ffff46f7d45 in QBasicMutex::lockInternal() () at /home/vadi/Programs/Qt/5.13.0/gcc_64/lib/libQt5Core.so.5 #2 0x00007ffff46f7dea in QMutex::lock() () at /home/vadi/Programs/Qt/5.13.0/gcc_64/lib/libQt5Core.so.5 #3 0x00005555556a93a7 in QMutexLocker::QMutexLocker(QBasicMutex*) (this=0x7fffffffbde8, m=0x5555570393e0) at ../../../Qt/5.13.0/gcc_64/include/QtCore/qmutex.h:206 #4 0x00005555556a9144 in debug_free(void*, char const*, int) (p=0x555557a74520, file=0x555555b5992c "unknown", line=0) at ../3rdparty/edbee-lib/edbee-lib/edbee/util/mem/debug_new.cpp:57 #5 0x00005555556a927c in operator delete(void*) (p=0x555557a74520) at ../3rdparty/edbee-lib/edbee-lib/edbee/util/mem/debug_new.cpp:90 #6 0x00007ffff7bce13d in void std::vector<TraceEdge, std::allocator<TraceEdge> >::_M_insert_aux<TraceEdge>(__gnu_cxx::__normal_iterator<TraceEdge*, std::vector<TraceEdge, std::allocator<TraceEdge> > >, TraceEdge&&) () at /tmp/.mount_heaptrRs0ned/opt/lib/heaptrack/libheaptrack_preload.so #7 0x00007ffff7bcc151 in heaptrack_malloc () at /tmp/.mount_heaptrRs0ned/opt/lib/heaptrack/libheaptrack_preload.so #8 0x00007ffff7bc8d98 in malloc () at /tmp/.mount_heaptrRs0ned/opt/lib/heaptrack/libheaptrack_preload.so #9 0x00007ffff470527d in QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlags<QArrayData::AllocationOption>) () at /home/vadi/Programs/Qt/5.13.0/gcc_64/lib/libQt5Core.so.5 #10 0x00007ffff470c4c4 in QByteArray::fromRawData(char const*, int) () at /home/vadi/Programs/Qt/5.13.0/gcc_64/lib/libQt5Core.so.5 #11 0x00007ffff48d8c66 in QMetaObjectPrivate::decodeMethodSignature(char const*, QVarLengthArray<QArgumentType, 10>&) () at /home/vadi/Programs/Qt/5.13.0/gcc_64/lib/libQt5Core.so.5 #12 0x00007ffff49021aa in QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) () at /home/vadi/Programs/Qt/5.13.0/gcc_64/lib/libQt5Core.so.5 #13 0x00007ffff6403267 in QMenu::actionEvent(QActionEvent*) () if it's a deadlock, can you get the backtrace for all threads please? to do so, run (gdb) thread apply all bt thanks Not sure if it was Heaptrack's fault - you're a better judge - but I fixed it by making edbee only do it's leak tracking only when asked to: https://github.com/edbee/edbee-lib/commit/98a823cfe0be18701709eeb7bae281bab430e3bb |