On 06/20/17 03:15 PM, Ali Nakipoglu wrote:
Hi,
Hope everyone very well.
Im working on a memory tracking tool that gets linked at run-time via
LD_PRELOAD. It's using libunwind to get stack trace information. With most
of the test applications its working fine but, there is one that libunwind
always crashes with the stack trace:
#0 0x00007ffff7bbfe74 in access_mem () from /build-debug/Intercept.so
#1 0x00007ffff7bbf724 in _Ux86_64_step () from /build-debug/Intercept.so
#2 0x00007ffff7bbc2b8 in Intercept::trace() () at
/src/Intercept/Intercept.cpp:185
#3 0x00007ffff7bbc4c3 in calloc () at src/Intercept/Intercept.cpp:252
#4 0x00007fffe35f1b33 in ?? () from /usr/lib64/nvidia/libGL.so.1
#5 0x00007fffcb50302e in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
#6 0x00007fffcb50c11b in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
#7 0x00007fffcb50d1b8 in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
#8 0x00007fffcb510c63 in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
#9 0x00007fffcb6686f3 in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
#10 0x00007fffcb63be54 in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
#11 0x00007fffcb63d647 in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
#12 0x00007fffcb655f24 in ?? () from
/usr/lib64/nvidia/libnvidia-glcore.so.375.39
Libunwind 1.2.1.
Is there a way to bypass it or its is a bug? Can CONSERVATIVE_CHECKS
(https://github.com/pathscale/libunwind/blob/1fcbfc649837d2a28e1901986437ca6bf9c4f4d4/src/x86_64/Gstep.c#L61)
build flag solve this?
You can try CONSERVATIVE_CHECKS. There is also a known issue if the
memory is mapped, but without PROT_READ. A potential fix is here:
https://github.com/libunwind/libunwind/pull/7