From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2163 invoked from network); 23 Jun 2020 12:12:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Jun 2020 12:12:38 -0000 Received: (qmail 26496 invoked by uid 550); 23 Jun 2020 12:12:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26476 invoked from network); 23 Jun 2020 12:12:33 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PBa0WwJvdjdJkv3f7puU/bTSqp8J2qbbhDE0VjrKkeQ=; b=lc7rsXVV08zeD7p8qQhCOPCYKeySPMMaxyxuNag1ruOmtKv5+NSkwPnflEl2euwf/r FveLCwMrfncbfBUh5Adc3d0H7qz7Klvfc/Gv/qdWAmyAb5nFAG7yqkSjY5F6VIPGXzK1 gWK1P3XjNCX86atgiOQjUIK0rr4XZgFFSIoMsiwkbKr9fby/ric/4wXXiwusgv5O2byA RUHsxou0hpCJN8wYxtZwuNRyPmj7QcP15JUZ3RJMqhTBZJm35J7BdAn800rVMQPUsxV+ +RtvZx/WMiI361qA81SVM7ajeMdqlyhonq9H6zDY2qTQunV6OoacSpYgattHNKZYX6zJ gDsg== X-Gm-Message-State: AOAM532sWaQ6ImXuH6wS1TNlnvO7IBBcfAtXSSJljzmXkKGim/THHno6 0Df+EDNiZcTmKK0d8jj6tWm3HABqReM= X-Google-Smtp-Source: ABdhPJyEIcqhMv6gnPTw0Eoe44gLu7aBU+1GoQZ2329hPV97btm7DDZCPbzjbcap1VYLGvhLS9a2kQ== X-Received: by 2002:a4a:7546:: with SMTP id g6mr18471144oof.51.1592914341712; Tue, 23 Jun 2020 05:12:21 -0700 (PDT) X-Received: by 2002:a9d:7083:: with SMTP id l3mr18819036otj.232.1592914341087; Tue, 23 Jun 2020 05:12:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Tue, 23 Jun 2020 15:12:08 +0300 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000755b9805a8bf45c3" Subject: Re: [musl] Better backtrace from core dump --000000000000755b9805a8bf45c3 Content-Type: text/plain; charset="UTF-8" Hi Install musl-dbg package to get the debug symbols. Timo On Tue, 23 Jun 2020, 14.43 Michal Nowak, wrote: > Hi, > > in GitLab we have jobs which run BIND system tests on different > operating system, mostly in Docker on Debian 10 but too in KVM virtual > machines for non-Linux operating systems. If the test produces core > dump, we generate backtrace out of it while still in the CI. > > For all C libraries but for musl we get reasonable backtraces, e.g. > https://gitlab.isc.org/isc-projects/bind9/-/jobs/970585, but for Alpine > Linux 3.11 (musl 1.1.24-r2 & GCC 9.2.0-r4) we get something like this > (https://gitlab.isc.org/isc-projects/bind9/-/jobs/970568): > > warning: Can't read pathname for load map: No error information. > Core was generated by > `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D statistics-ns3 > -X named.'. > Program terminated with signal SIGABRT, Aborted. > #0 0x00007fb708ec39ee in setjmp () from /lib/ld-musl-x86_64.so.1 > [Current thread is 1 (LWP 1274)] > #0 0x00007fb708ec39ee in setjmp () from /lib/ld-musl-x86_64.so.1 > #1 0x00007fb708ec3b49 in raise () from /lib/ld-musl-x86_64.so.1 > #2 0x804ad6685d596f46 in ?? () > #3 0x00007fb708bd1030 in ns_modules () from > /builds/isc-projects/bind9/lib/ns/.libs/libns.so.1702 > #4 0x00007fb708e59edf in ?? () from > /builds/isc-projects/bind9/lib/isc/.libs/libisc.so.1702 > #5 0x0000000042756621 in ?? () > #6 0x00007fb7069c9db0 in ?? () > #7 0x0000001800000018 in ?? () > #8 0x00007fb708f0e873 in ?? () from /lib/ld-musl-x86_64.so.1 > #9 0x0000000000000008 in ?? () > #10 0x00007fb7069ca0e8 in ?? () > #11 0x00007fb7069ca0d0 in ?? () > #12 0x00007fb708e32d12 in isc_hash_function (data=0x459, length=0, > case_sensitive=) at hash.c:117 > > This is how we generate the backtrace: > > "${top_builddir}/libtool" --mode=execute gdb --batch > --command=run.gdb --core="$coredump" -- "$binary" > > The GDB command can be either 'bt' or 'thread apply all bt full' (for > more on the GDB invocation, see > > https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/tests/system/run.sh.in#L268 > ). > > CFLAGS used: > > -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra > > This is what we install on top of the stock Alpine Linux 3.11 Docker > image: > > https://gitlab.isc.org/isc-projects/images/-/blob/main/docker/bind9/alpine-template/Dockerfile. > > Are there other packages, we should get into the image to get better > backtraces? > > Should we use something else than GDB? > > Should we add some compiler flags? > > Thanks, > Michal > --000000000000755b9805a8bf45c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

Install m= usl-dbg package to get the debug symbols.

=
Timo

On Tue, 23 Jun 2020, 14.43 Michal Nowak, <= mnowak@isc.org> wrote:
Hi,

in GitLab we have jobs which run BIND system tests on different
operating system, mostly in Docker on Debian 10 but too in KVM virtual
machines for non-Linux operating systems. If the test produces core
dump, we generate backtrace out of it while still in the CI.

For all C libraries but for musl we get reasonable backtraces, e.g.
https://gitlab.isc.org/isc-project= s/bind9/-/jobs/970585, but for Alpine
Linux 3.11 (musl 1.1.24-r2 & GCC 9.2.0-r4) we get something like this <= br> (https://gitlab.isc.org/isc-projec= ts/bind9/-/jobs/970568):

warning: Can't read pathname for load map: No error information.
Core was generated by
`/builds/isc-projects/bind9/bin/named/.libs/lt-named -D statistics-ns3
-X named.'.
Program terminated with signal SIGABRT, Aborted.
#0=C2=A0 0x00007fb708ec39ee in setjmp () from /lib/ld-musl-x86_64.so.1
[Current thread is 1 (LWP 1274)]
#0=C2=A0 0x00007fb708ec39ee in setjmp () from /lib/ld-musl-x86_64.so.1
#1=C2=A0 0x00007fb708ec3b49 in raise () from /lib/ld-musl-x86_64.so.1
#2=C2=A0 0x804ad6685d596f46 in ?? ()
#3=C2=A0 0x00007fb708bd1030 in ns_modules () from
/builds/isc-projects/bind9/lib/ns/.libs/libns.so.1702
#4=C2=A0 0x00007fb708e59edf in ?? () from
/builds/isc-projects/bind9/lib/isc/.libs/libisc.so.1702
#5=C2=A0 0x0000000042756621 in ?? ()
#6=C2=A0 0x00007fb7069c9db0 in ?? ()
#7=C2=A0 0x0000001800000018 in ?? ()
#8=C2=A0 0x00007fb708f0e873 in ?? () from /lib/ld-musl-x86_64.so.1
#9=C2=A0 0x0000000000000008 in ?? ()
#10 0x00007fb7069ca0e8 in ?? ()
#11 0x00007fb7069ca0d0 in ?? ()
#12 0x00007fb708e32d12 in isc_hash_function (data=3D0x459, length=3D0,
case_sensitive=3D<optimized out>) at hash.c:117

This is how we generate the backtrace:

=C2=A0 =C2=A0"${top_builddir}/libtool" --mode=3Dexecute gdb --bat= ch
--command=3Drun.gdb --core=3D"$coredump" -- "$binary"
The GDB command can be either 'bt' or 'thread apply all bt full= ' (for
more on the GDB invocation, see
http= s://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/tests/system/run.sh.i= n#L268).

CFLAGS used:

=C2=A0 =C2=A0-fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wa= ll -Wextra

This is what we install on top of the stock Alpine Linux 3.11 Docker
image:
https://gitlab.isc.org/isc-projects/images/-/blob/main/docker/bind9/al= pine-template/Dockerfile.
Are there other packages, we should get into the image to get better
backtraces?

Should we use something else than GDB?

Should we add some compiler flags?

Thanks,
Michal
--000000000000755b9805a8bf45c3--