From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by sourceware.org (Postfix) with ESMTPS id D502C3858D20 for ; Fri, 4 Feb 2022 14:09:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D502C3858D20 Received: by mail-lf1-x131.google.com with SMTP id bu18so12895400lfb.5 for ; Fri, 04 Feb 2022 06:09:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Ee+dm0rN4IVgeDvPEZEP9jm0iy/kzUSWplQcn0RNjwg=; b=GpvEZS5HiS9+UEDnkaY4G35ulqKyZNIgGjhInGG49mdJP53TGSCKtbM95Ucwm4rYa8 i8LMjzHQTui8/vb+54VB7vUxt4KPwJCcRoINyRWqxk9UQDlDXqt7QZlX2Yhm7mhs3dMn 0IWNIQ8zk8C3GkUAAiOy6q/NSzXTA2JX4NyL43kZWPPiA1L664Kr5QCh36F9F/gZCY21 Anw0H9fW2YAoPJkI7Im3D3A6NTYvvKq0bScYI6R+8yWP1jyhj9KhBZb6EMep65JArmow HK7A/WCTTVi1RPo9mHPKXwdFP12AqM1RnSLRy7FbNeo/RnEOcNtru6X4OOyOYNyRGoC7 ZXQA== X-Gm-Message-State: AOAM531/snQVyI2TNPfEvN3IlT+gtNHEHUXZscDF/rgAPe+UugmCZAIf MDSStRkaIBufLJWeO/VKMFM= X-Google-Smtp-Source: ABdhPJxBIzKpa812aqjyFtA/pqTl7yvIKQP2yio5SaXToHGlWGpOn8EhgjsNhtYypor1h4ONE4EGsA== X-Received: by 2002:a05:6512:3f03:: with SMTP id y3mr2426120lfa.515.1643983783596; Fri, 04 Feb 2022 06:09:43 -0800 (PST) Received: from [192.168.10.175] (37-247-29-68.customers.ownit.se. [37.247.29.68]) by smtp.gmail.com with ESMTPSA id c7sm331889lfp.10.2022.02.04.06.09.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Feb 2022 06:09:43 -0800 (PST) Message-ID: Date: Fri, 4 Feb 2022 15:09:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Debugging ld.so in gdb Content-Language: en-US To: Florian Weimer , Jacob Kroon via Gdb References: <29e0ef71-4706-9b0f-2a68-e12c54120d8e@gmail.com> <8735kypwcd.fsf@oldenburg.str.redhat.com> From: Jacob Kroon In-Reply-To: <8735kypwcd.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 14:09:47 -0000 Hi Florian, On 2/4/22 14:58, Florian Weimer wrote: > * Jacob Kroon via Gdb: > >> Since a week or two I have started to see a segfault on my updated >> Fedora 35 system. I suspect the segfault is related to a recent glibc >> update. >> >> The segfault I see happens when I run the following: >> >> $ ldd ./mylib.so >> >> I narrowed it down to running: >> >> $ LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 ./mylib.so >> >> "coredumpctl info" gives me: >> >>> Stack trace of thread 143567: >>> #0 0x00007ff428f73590 n/a (n/a + 0x0) >>> #1 0x00007ff428f8af0f _dl_map_object_deps (/usr/lib64/ld-linux-x86-64.so.2 + 0x3f0f) >>> #2 0x00007ff428fa6970 dl_main (/usr/lib64/ld-linux-x86-64.so.2 + 0x1f970) >>> #3 0x00007ff428fa2c7c _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2 + 0x1bc7c) >>> #4 0x00007ff428fa4678 _dl_start_final (/usr/lib64/ld-linux-x86-64.so.2 + 0x1d678) >>> #5 0x00007ff428fa36a8 _start (/usr/lib64/ld-linux-x86-64.so.2 + 0x1c6a8) >> >> but inspecting in gdb using "coredumpctl debug" doesn't give me any sane >> backtrace. >> >> The .so is part of a Yocto build. If I copy the file out from its build >> directory to $HOME and run ldd on it, then there is no crash. So I >> suspect RUNPATH is involved somehow since it contains $ORIGIN. >> >> Any ideas of what I can do to investigate further ? > > I suggest to run ld.so under GDB, with > > set startup-with-shell off > set environment LD_TRACE_LOADED_OBJECTS 1 > b _start > run ./mylib.so > record btrace pt > continue > > And after the crash, look at > > record instruction-history > > to see how it reached the crash. This assumes that you have an > execution environment that supports branch tracing. > This is what I get, following the instructions above: > 171966 0x00007ffff7fd85a0 : mov 0x0(%r13),%rax > 171967 0x00007ffff7fd85a4 : lea -0x8(%rax),%rdx > 171968 0x00007ffff7fd85a8 : mov %rdx,0x0(%r13) > 171969 0x00007ffff7fd85ac : mov %rbp,-0x8(%rax) > 171970 0x00007ffff7fd85b0 : add $0x8,%rsp > 171971 0x00007ffff7fd85b4 : pop %rbx > 171972 0x00007ffff7fd85b5 : pop %rbp > 171973 0x00007ffff7fd85b6 : pop %r12 > 171974 0x00007ffff7fd85b8 : pop %r13 > 171975 0x00007ffff7fd85ba : ret Does that make sense ? Any other information I can provide. This is with glibc-2.34-24.fc35.x86_64, Fedora 35. Regards Jacob