From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 488113857C49 for ; Mon, 22 Aug 2022 10:52:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 488113857C49 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-400-8MKKKdVfMs-kJGG5_pam6A-1; Mon, 22 Aug 2022 06:52:19 -0400 X-MC-Unique: 8MKKKdVfMs-kJGG5_pam6A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8E473803301; Mon, 22 Aug 2022 10:52:19 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.199]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B6C4B1410DD5; Mon, 22 Aug 2022 10:52:18 +0000 (UTC) From: Florian Weimer To: Jonny Grant Cc: libc-help@sourceware.org Subject: Re: ld-linux-x86-64 core file SIGSEGV References: <87a67w6aqn.fsf@oldenburg.str.redhat.com> <87o7wczhgi.fsf@oldenburg.str.redhat.com> <34136fcb-da3c-f8f7-d091-ec1c8b3c187e@jguk.org> Date: Mon, 22 Aug 2022 12:52:16 +0200 In-Reply-To: <34136fcb-da3c-f8f7-d091-ec1c8b3c187e@jguk.org> (Jonny Grant's message of "Mon, 22 Aug 2022 11:47:29 +0100") Message-ID: <87fshozh27.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2022 10:52:22 -0000 * Jonny Grant: > On 22/08/2022 11:43, Florian Weimer wrote: >> * Jonny Grant: >> >>> I got it to load the debug symbol using "file" command you >>> mentioned. Unfortunately backtrace still empty. The debug symbols >>> /usr/lib/debug/.build-id/61/ef896a699bb1c2e4e231642b2e1688b2f1a61e.debug >>> are only 592,952 bytes >>> >>> I would probably just prefer if binaries weren't separated from their >>> debug symbols. Do you know any distributions that don't strip symbols >>> from glibc? >> >> I'm not sure if this is caused by debuginfo separation. I run into GDB >> when I use my own custom-built glibc with unstripped debuginfo. >> >> Anyway, you can probably use eu-unstrip from elfutils to undo the >> debuginfo separation. >> >> Thanks, >> Florian > > That's a good tip than you. > > I did use objdump -d on the ld.so, but couldn't spot anything similar > to what I saw in "layout asm" from gdb. In my experience, the missing symbols are usually from the main program, and then the stack backtrace runs off the rails pretty quickly (resulting in garbage addresses). > Is it ever possible to match up disassembly with the gdb core > disassembly this way? You cloud get the object addresses from /proc/PID/mem, compute the relative offset, and then use addr2line or objdump to find out more. Thanks, Florian