libunwind-devel
[Top][All Lists]
Advanced

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

[Libunwind-devel] [aarch64] segfault (non valid c->dwarf.ip) in _ULaarch


From: David Abdurachmanov
Subject: [Libunwind-devel] [aarch64] segfault (non valid c->dwarf.ip) in _ULaarch64_is_signal_frame (vDSO symbol before signal frame)
Date: Tue, 12 Aug 2014 11:22:48 +0200

Hi,

I have encountered problems with vDSO and libunwind on complex application. We 
are running a complex C++11 application with deep stack traces. We are using a 
performance profiler (IgProf), which depends on libunwind to produce the stack 
trace. If our stack trace contains vDSO symbol (__kernel_rt_sigreturn, 
__kernel_gettimeofday, __kernel_clock_gettime, and __kernel_clock_getres) 
before signal frame (entering IgProf), _ULaarch64_is_signal_frame will 
segfault, because `c->dwarf.ip' will return non valid IP (random), e.g., 0x1.

It works fine if we execute a small test case calling particular glibc wrappers 
multiple times, e.g.

#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

int
main(void)
{
 struct timeval tv;
 struct timezone tz;
 struct timespec ta;
 time_t seconds;
 for(int i = 0; i < 10000000; ++i) {
   gettimeofday(&tv, &tz);
   seconds = time(NULL);
   clock_gettime (CLOCK_REALTIME, &ta);
 }
}

E.g., stack trace:

#0  0x0000007f8ecfd1c0 in waitpid () from /lib64/libc.so.6
#1  0x0000007f8ec9a530 in do_system () from /lib64/libc.so.6
#2  0x0000007f91c05c38 in dosystem(const char *, IgHook::SafeData<int(char 
const*)> &, IgHook::SafeData<int(char const*)> &) (cmd=0x7f74b2ae00 
"/home/david.abdurachmanov/testing-ib/cmsinst/fc19_aarch64_gcc490/lcg/root/5.34.18/etc/gdb-backtrace.sh
 17712 1>&2", hook=..., hook=...) at 
/home/david.abdurachmanov/testing-igprof/a/BUILD/fc19_aarch64_gcc490/external/i
gprof/5.9.10-b941e3c2/igprof-b941e3c2c29651e4beb89b1ad9d440efa493d830/src/profile-perf.cc:358
#3  0x0000007f90308660 in TUnixSystem::StackTrace() () from 
/home/david.abdurachmanov/testing-ib/cmsinst/fc19_aarch64_gcc490/cms/cmssw/CMSSW_7_2_0_pre1/external/fc19_aarch64_gcc490/
lib/libCore.so
#4  0x0000007f88269148 in sig_dostack_then_abort () from 
/home/david.abdurachmanov/testing-ib/cmsinst/fc19_aarch64_gcc490/cms/cmssw/CMSSW_7_2_0_pre1/lib/fc19_aarch64_gcc490/libFWCoreServices.so
#5  <signal handler called>
#6  _ULaarch64_is_signal_frame (cursor=cursor
entry=0x7fe3f52410) at aarch64/Gis_signal_frame.c:52
#7  0x0000007f8ec0b260 in _ULaarch64_step (cursor=cursor
entry=0x7fe3f52410) at aarch64/Gstep.c:118
#8  0x0000007f8ec09d3c in slow_backtrace (uc=0x7fe3f49270, size=127, 
buffer=0x7f8efb5450) at mi/backtrace.c:45
#9  unw_backtrace (buffer=0x7f8efb5450, size=127) at mi/backtrace.c:72
#10 0x0000007f91c05870 in profileSignalHandler () at 
/home/david.abdurachmanov/testing-igprof/a/BUILD/fc19_aarch64_gcc490/external/igprof/5.9.10-b941e3c2/igprof-b941e3c2c29651e4beb89b1ad9d440efa493d830/src/profile-perf.cc:66
#11 <signal handler called>
#12 0x0000007f91c502f4 in __kernel_gettimeofday ()
#13 0x0000007f8ecef1b0 in gettimeofday () from /lib64/libc.so.6
#14 0x0000007f8ecef16c in time () from /lib64/libc.so.6
#15 0x0000007f75bc0c00 in frontier_str_now (buf=0x7f75bbf730 
<frontier::Session::getData(std::vector<frontier::Request const*, 
std::allocator<frontier::Request const*> > const&)+1068> "\240\257", buf
entry=0x7fe3f5d180 
"JGiL0kPj6x/eX4d45dWFlZKeEKNrDpUF0rgGnWjEtsvS8ffgBze+B1rqoYOop1ZKnfkHUExiNh\n6Oiygqmtkhn+naHfRMZt7pmzl5z5Q7dUUqkZ5rRzE6zVQ3huqB6LY2it/fgJr91mGLQURSd1m//p\n8KDJ5/e+")
 at frontier.c:110
[snip]  

From GDB:

Program received signal SIGSEGV, Segmentation fault.
access_mem (as=0x7fb4fd1710 <local_addr_space>, addr=1, val=0x7ffffe2dc8, 
write=0, arg=0x7ffffe2e40) at aarch64/Ginit.c:94
94            *val = *(unw_word_t *) addr;


In unw_is_signal_frame (unw_cursor_t *cursor)

 as = c->dwarf.as;
 a = unw_get_accessors (as);
 arg = c->dwarf.as_arg;

 ip = c->dwarf.ip;

 ret = (*a->access_mem) (as, ip, &w0, 0, arg);


Has anyone else encountered a similar problem? As you can see GDB managed to 
produce a stack trace on crash.

Current solution is to disable profiling around code path with vDSO symbols and 
it works, but doesn't solve the actual problem.

Tested on Fedora 19 Remix.

Thanks,
david


reply via email to

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