https://bugs.kde.org/show_bug.cgi?id=390893
Milian Wolff changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |UPSTREAM
--- Comment #5 from Milian Wolff ---
A java application - interesting, never used heaptrack on that. The crash
itself happens within libunwind:
Thread 56 (Thread 0x7ffeff661700 (LWP 5926)):
#0 0x771d9428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x771db02a in __GI_abort () at abort.c:89
#2 0x755eeed5 in os::abort(bool) () from
/path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#3 0x75792a33 in VMError::report_and_die() () from
/path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#4 0x755f4def in JVM_handle_linux_signal () from
/path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#5 0x755eaea3 in signalHandler(int, siginfo*, void*) () from
/path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#6 0x in handleCustom (sc_=, si=, code=11, handlerCode=11) at ??
#7 mySignalHandler (code=11, si=, sc_=) at ??
#8
#9 access_mem (as=, addr=29930553589, val=0x7ffeff65eb90,
write=, arg=) at x86_64/Ginit.c:175
#10 0x76f8829c in dwarf_get (c=0x7ffeff65f090, c=0x7ffeff65f090,
val=0x7ffeff65eb90, loc=...) at ../include/tdep-x86_64/libunwind_i.h:167
#11 _ULx86_64_step (cursor=cursor@entry=0x7ffeff65f090) at x86_64/Gstep.c:166
#12 0x76f8942c in trace_init_addr (rsp=, rbp=, rip=, cfa=31901497176, cursor=0x7ffeff65f090,
f=0x7fff4bfdc940) at x86_64/Gtrace.c:248
#13 trace_lookup (rsp=, rbp=, rip=, cfa=31901497176, cache=, cursor=0x7ffeff65f090) at
x86_64/Gtrace.c:330
#14 _ULx86_64_tdep_trace (cursor=cursor@entry=0x7ffeff65f090,
buffer=buffer@entry=0x7ffeff65f928, size=size@entry=0x7ffeff65ecd4) at
x86_64/Gtrace.c:447
#15 0x76f85db2 in unw_backtrace (buffer=0x7ffeff65f928, size=64) at
mi/backtrace.c:69
#16 0x77bc19e0 in Trace::fill (this=0x7ffeff65f920, skip=3) at
/home/jcoulon/git/heaptrack/src/track/trace.h:61
#17 0x77bbfbd0 in heaptrack_malloc (ptr=0x7ffec406b160, size=8) at
/home/jcoulon/git/heaptrack/src/track/libheaptrack.cpp:638
#18 0x77bbd9dd in malloc (size=8) at
/home/jcoulon/git/heaptrack/src/track/heaptrack_preload.cpp:176
#19 0x76c8ee78 in operator new(unsigned long) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#20 0x7fff3a40f08e in __gnu_cxx::new_allocator::allocate
(this=, __n=) at
/usr/include/c++/4.9/ext/new_allocator.h:104
#21 0x in ?? ()
Probably it tries to access invalid memory, triggering a signal which then
leads to the crash. To fix this, you'll have to fix libunwind, which is going
to be tough. First, you'll need to figure out whom to blame - is it a bug in
libunwind? Or is the DWARF data corrupt, misleading it? Can the latter be
handled somehow?
One way or another, this isn't a bug within heaptrack itself. It definitely
makes the tool unusable for you, but it's nothing that can be workarounded from
within heaptrack - it has to be fixed upstream (either libunwind or in the
DWARF emitter).
--
You are receiving this mail because:
You are watching all bug changes.
