libunwind-devel
[Top][All Lists]
Advanced

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

Re: [Libunwind-devel] Backtrace on linux_x86_64 having a weird behavior


From: hai huang
Subject: Re: [Libunwind-devel] Backtrace on linux_x86_64 having a weird behavior with binary compiled with gcc -O2 flag
Date: Wed, 16 Aug 2017 14:31:42 -0400

Well, maybe these types of vdso calls cannot be traced. Here's the source code to vdso_gettimeofday in the kernel: https://github.com/torvalds/linux/blob/v3.13/arch/x86/vdso/vclock_gettime.c#L260

I'm not familiar with the keyword `notrace` in the function declaration, but it sounds like that function is not meant to be traced, thus the problem I'm facing?

-
Hai

On Wed, Aug 16, 2017 at 2:08 PM, hai huang <address@hidden> wrote:
Dave, after some digging, I also realized that some syscalls are being handled as vdso calls, such as gettimeofday. However, if they are vdso calls, I shouldn't be able to see them using ptrace when collecting only syscalls. The weird thing is I see a lot of gettimeofday syscalls being made. Then I stumbled upon this article here: https://stackoverflow.com/questions/42622427/gettimeofday-not-using-vdso, which describes why some vdso calls on Xen VMs are actually real syscalls.

I guess the problem I'm really having is that for some syscalls being handled as vdso calls, but due to specific virtualization platform (Xen), are eventually handled as real syscalls, their backtrace seems to be screwed up. Is there something special in those couple of vdso pages that kernel sets up that libunwind will need some kind of workaround to get a proper backtrace?

Thanks!

-
Hai

On Wed, Aug 16, 2017 at 1:07 PM, Dave Watson <address@hidden> wrote:
On 08/16/17 09:50 AM, hai huang wrote:
> Actually, this problem can be reproduced with an even simpler program:
>
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/time.h>
>
> int main() {
>         struct timeval tv;
>         gettimeofday(&tv, NULL);
> }
>
>
> If I compile this with `gcc -O2 -o test_O2 test.c` and run
> `libunwind/tests/test-ptrace -s -v ./test_O2` to trace it, I will get the
> same behavior as above with `main+0x1e` showing up twice in the backtrace.
> However, the weird thing is if I replace gettimeofday() call with a
> sleep(1) call, even compiling with the `-O2` flag, backtrace looks fine.
> Maybe there's a strange interaction between libunwind and gettimeofday
> syscall?

So my first guess would be that it's because you are trying to ptrace
and backtrace syscalls, but gettimeofday is no longer a syscall on
modern linux systems, it's a vdso call:

https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86_64/gettimeofday.c#L34

And this is why sleep works fine - it's stil a normal syscall



reply via email to

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