From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 80F2F3858D32 for ; Mon, 22 Aug 2022 10:27:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 80F2F3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-wr1-x433.google.com with SMTP id n7so12608954wrv.4 for ; Mon, 22 Aug 2022 03:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=TAYnMc5xaVLYQ+ky5NdEKLwmipjQ1Zr+ACVw7Sam91M=; b=rEMcYV5mIjdmC+5g7rXQzO3JihCdVSqj/kERdLJznBHkxcyZew59Rroui4yWeMgWnp bCYNLZ2FAfo8b1i98zMRG+/16z6m2YvFJcPSjOhhWQagGJL0ZRtlTK8lV6slkk36nZ6V bPw2kMi8z7JoUuZzGX4xr1IxN66m7f5H9JdwEuBJopFhuuv7bd/tTsnM5gLvcUfqTXRb Yj4O1Ipo+Ji3hmrmgnjmPvHIxNz1Eil45mMY1EnrY1CNvJaMiafwZXzDcZiu/wkI2Wfi jqLD3SZk8Fu4PRkxqHLXRyDm43NDvCB+Xo/AxrpCAFbsVDczxxA6sCL6ElQ8/F3VDdIM lf5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=TAYnMc5xaVLYQ+ky5NdEKLwmipjQ1Zr+ACVw7Sam91M=; b=rTK2wkHBsnyRbI9odZg2LzD68RJ1NEgxozRCB6VAfypHecSa2b8BbKqdxUl7FowpFP nL6nGLNkHmKGAppGDiF9B7FV6JIs36qwq1zTbk5a/BLAxP/8nC4Fiyj68UD2Wpk6W1e2 2M+n4DO9P+8C2CNmWGxF9sHkklYD1aIivp/Hn09a0ZLzzhr8OmLFkmAvMqa1URpfWTmn 71NcA26FMWGCS/Sh00CrFTgMLVGLwcZrKB2IXMbXAJwfw7PJ7ObG4rLHlxpKhR6KZqR7 G/+DLsbgEmJebWoC39SEJ6D4wtXABlCBDnldQW33sp5tHEQ1sLR5HDuRKGUfdk8OiX/c pnCQ== X-Gm-Message-State: ACgBeo081SzFBGA6XtEc0JLHtntaciQETGAb9I1mVFl9iVYlm+OzJeu8 xEbBza5jvBd9OnkJDoWaKO8/Eg== X-Google-Smtp-Source: AA6agR6VlZUhryXdeUpNCYLJPZMm2cVGqvG76fJ8IJuN8W35hGsZjOjq3B0WaAJ6HmmEdcjDBgH1jg== X-Received: by 2002:a5d:6881:0:b0:225:28cb:332f with SMTP id h1-20020a5d6881000000b0022528cb332fmr10368976wru.405.1661164019288; Mon, 22 Aug 2022 03:26:59 -0700 (PDT) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id g12-20020adfa48c000000b00224f5bfa890sm11746068wrb.97.2022.08.22.03.26.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Aug 2022 03:26:58 -0700 (PDT) Message-ID: Date: Mon, 22 Aug 2022 11:26:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: ld-linux-x86-64 core file SIGSEGV Content-Language: en-GB To: Florian Weimer Cc: libc-help@sourceware.org References: <87a67w6aqn.fsf@oldenburg.str.redhat.com> From: Jonny Grant In-Reply-To: <87a67w6aqn.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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:27:02 -0000 On 22/08/2022 07:41, Florian Weimer wrote: > * Jonny Grant: > >> Hello >> I have a core file from a crash in glibc's ld.so >> >> Couldn't reproduce it. Was just wondering if there was any useful info >> I could extract to identify which function it crashed in? > >> I can see the backtrace using 'bt' command. >> I can see the assembly using 'layout asm' >> >> >> Core was generated by `/lib64/ld-linux-x86-64.so.2 /usr/lib/vmware/lib/libvmware-modconfig.so/libvmwar'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 0x00007fac33ccb540 in ?? () >> (gdb) bt >> #0 0x00007fac33ccb540 in () >> #1 0x00007fac33ccea00 in () >> #2 0x00007fac33ccdfa0 in () >> #3 0x00007fac33c496b0 in () >> #4 0x00007fac33c49bf0 in () >> #5 0x00007fac33c4a130 in () >> #6 0x00007fac33ccd000 in () >> #7 0x00007fac33c4a670 in () >> #8 0x00007fac31cdf310 in () at /usr/lib/vmware/lib/libvmwarebase.so/libvmwarebase.so >> >> >> installing libc6-amd64-dbgsym doesn't show any more > > Sometimes it's possible to get better backtraces by loading the symbol > table for the name program using “file”, running ld.so and the program > under the debugger, or both. I've got a request open with our GDB > developers to improve debugging with an explicit ld.so invocation, but > so far, it's a known issue. > > Thanks, > Florian > Hi Florian Thank you for your reply with suggestion. 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? Kind regards Jonny