netdev - Re: [PATCH v2 bpf-next] selftests/bpf: print backtrace on SIGSEGV in test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f4ae621b-a783-1a77-3a06-b7eb5afdfc4e@iogearbox.net>
Date:   Tue, 25 Feb 2020 22:58:25 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Andrii Nakryiko <andriin@...com>, bpf@...r.kernel.org,
        netdev@...r.kernel.org, ast@...com
Cc:     andrii.nakryiko@...il.com, kernel-team@...com
Subject: Re: [PATCH v2 bpf-next] selftests/bpf: print backtrace on SIGSEGV in
 test_progs

On 2/25/20 1:08 AM, Andrii Nakryiko wrote:
> Due to various bugs in tests clean up code (usually), if host system is
> misconfigured, it happens that test_progs will just crash in the middle of
> running a test with little to no indication of where and why the crash
> happened. For cases where coredump is not readily available (e.g., inside
> a CI), it's very helpful to have a stack trace, which lead to crash, to be
> printed out. This change adds a signal handler that will capture and print out
> symbolized backtrace:
> 
>    $ sudo ./test_progs -t mmap
>    test_mmap:PASS:skel_open_and_load 0 nsec
>    test_mmap:PASS:bss_mmap 0 nsec
>    test_mmap:PASS:data_mmap 0 nsec
>    Caught signal #11!
>    Stack trace:
>    ./test_progs(crash_handler+0x18)[0x42a888]
>    /lib64/libpthread.so.0(+0xf5d0)[0x7f2aab5175d0]
>    ./test_progs(test_mmap+0x3c0)[0x41f0a0]
>    ./test_progs(main+0x160)[0x407d10]
>    /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f2aab15d3d5]
>    ./test_progs[0x407ebc]
>    [1]    1988412 segmentation fault (core dumped)  sudo ./test_progs -t mmap
> 
> Unfortunately, glibc's symbolization support is unable to symbolize static
> functions, only global ones will be present in stack trace. But it's still a
> step forward without adding extra libraries to get a better symbolization.
> 
> Signed-off-by: Andrii Nakryiko <andriin@...com>

Applied, thanks!