libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libunwind-devel] Crash in access_mem at x86_64/Ginit.c:175


From: Jérémy Coulon
Subject: [Libunwind-devel] Crash in access_mem at x86_64/Ginit.c:175
Date: Fri, 23 Feb 2018 10:30:18 +0100

Hello!

I am having a crash in libunwind while using heaptrack to profile my application.

Here is the callstack:
Thread 56 (Thread 0x7ffeff661700 (LWP 5926)):
#0  0x00007ffff71d9428 in __GI_raise (address@hidden) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff71db02a in __GI_abort () at abort.c:89
#2  0x00007ffff55eeed5 in os::abort(bool) () from /path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#3  0x00007ffff5792a33 in VMError::report_and_die() () from /path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#4  0x00007ffff55f4def in JVM_handle_linux_signal () from /path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#5  0x00007ffff55eaea3 in signalHandler(int, siginfo*, void*) () from /path/to/mysdk/build/java/1.8.152-0/amd64-linux/lib/amd64/server/libjvm.so
#6  0x0000xxxxxxxxxxxx in handleCustom (sc_=<optimized out>, si=<optimized out>, code=11, handlerCode=11) at ??
#7  mySignalHandler (code=11, si=<optimized out>, sc_=<optimized out>) at ??
#8  <signal handler called>
#9  access_mem (as=<optimized out>, addr=29930553589, val=0x7ffeff65eb90, write=<optimized out>, arg=<optimized out>) at x86_64/Ginit.c:175
#10 0x00007ffff6f8829c in dwarf_get (c=0x7ffeff65f090, c=0x7ffeff65f090, val=0x7ffeff65eb90, loc=...) at ../include/tdep-x86_64/libunwind_i.h:167
#11 _ULx86_64_step (address@hidden) at x86_64/Gstep.c:166
#12 0x00007ffff6f8942c in trace_init_addr (rsp=<optimized out>, rbp=<optimized out>, rip=<optimized out>, cfa=31901497176, cursor=0x7ffeff65f090, f=0x7fff4bfdc940) at x86_64/Gtrace.c:248
#13 trace_lookup (rsp=<optimized out>, rbp=<optimized out>, rip=<optimized out>, cfa=31901497176, cache=<optimized out>, cursor=0x7ffeff65f090) at x86_64/Gtrace.c:330
#14 _ULx86_64_tdep_trace (address@hidden, address@hidden, address@hidden) at x86_64/Gtrace.c:447
#15 0x00007ffff6f85db2 in unw_backtrace (buffer=0x7ffeff65f928, size=64) at mi/backtrace.c:69
#16 0x00007ffff7bc19e0 in Trace::fill (this=0x7ffeff65f920, skip=3) at /home/jcoulon/git/heaptrack/src/track/trace.h:61
#17 0x00007ffff7bbfbd0 in heaptrack_malloc (ptr=0x7ffec406b160, size=8) at /home/jcoulon/git/heaptrack/src/track/libheaptrack.cpp:638
#18 0x00007ffff7bbd9dd in malloc (size=8) at /home/jcoulon/git/heaptrack/src/track/heaptrack_preload.cpp:176
#19 0x00007ffff6c8ee78 in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#20 0x00007fff3a40f08e in __gnu_cxx::new_allocator<unsigned long>::allocate (this=<optimized out>, __n=<optimized out>) at /usr/include/c++/4.9/ext/new_allocator.h:104
#21 0x0000xxxxxxxxxxxx in ?? ()
I already reported this bug to heaptrack here:
https://bugs.kde.org/show_bug.cgi?id=390893

Maintainer of heaptrack thinks that the bug is in libunwind itself.

I am using:
* heaptrack version v1.0.0-119-g6e31841
* libunwind version v1.2-3-gac02808

I also noticed this report on the mailing list which look similar to my problem:
http://lists.nongnu.org/archive/html/libunwind-devel/2017-12/msg00001.html

Unfortunately I couldn't make an simple open source example from my complex proprietary app in order to reproduce the crash.

Thank you for your help.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]