From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 28273386F430 for ; Thu, 14 May 2020 19:12:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 28273386F430 Received: by mail-lj1-x22d.google.com with SMTP id e25so4769442ljg.5 for ; Thu, 14 May 2020 12:12:41 -0700 (PDT) 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:cc; bh=nfdJ9+t4T8m3a88fe040iA1SZ0jh/xNnUYI0VukVxGs=; b=ZvAGUg1YrjyQVHbhWiraDujmlnFG9EeVD7QFDMZsXmpZAJrR2g6Kxnzp8FuzVBmoV8 N/OeRCSu0MmsJdleyN3zr9b6XTey+OzO2cks5IztwZIkSrKij4C4KAjuXNWp/GU0MaZa QCdfwAWzfatT15k5dzFc9Qup2PqM85ZDEUE03weFCisWPojE9+0TX8fobif7xwm7jZl1 Cmjh5TlA99hqCqxl4EGp7k8s7qybyIjpo4fs6g5ZPaqCsM86PzPacL0KDYLxkC+Pq7at qlk3JPpt0jPhSsXHJYqSB7GNgweU40y7smlS0tnPA17KfuJgqAN/Zm2uv0sicmLW8zck DH+Q== X-Gm-Message-State: AOAM532VfBMxb10yLfbggXrCZ8KHgd1q6j0V9QhmncNo6gIUNuF3DM39 xs/2St6FuXlWUYSK8wFxcSZYEK3nFgio4slnU3NCrg== X-Google-Smtp-Source: ABdhPJxdTIV4wmJ8kmKjITIVteDTiujV6ngnCuttrTyePsmvCJZ6k4yuc2caHVGBurfKxw2VTFVhR8/R+M9h9lEqU9A= X-Received: by 2002:a2e:711c:: with SMTP id m28mr899861ljc.104.1589483559737; Thu, 14 May 2020 12:12:39 -0700 (PDT) MIME-Version: 1.0 References: <072e4b2b-4d71-b343-c8ef-0edbc6ab6804@simark.ca> In-Reply-To: From: mlimber Date: Thu, 14 May 2020 15:12:28 -0400 Message-ID: Subject: Re: [PATCH] [PR 25678] gdb crashes with "internal-error: sect_index_text not initialized" when .text To: Simon Marchi Cc: gdb-patches@sourceware.org X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 19:12:51 -0000 Unfortunately, the simpler repro cases I have tried don't trigger the failure, e.g., // main.c extern int g_global_var; int main() { return g_global_var; } // libglobal.c extern int g_global_var; int g_global_var = 42; I build it like: gcc -shared -nostdlib -fPIC -o libglobal.so libglobal.c gcc -o main main.c -lglobal -L. -Wl,--rpath,\$ORIGIN Running it in GDB works fine. Seems like something more is required. Even following the repro steps listed in the first comment or linking against libicudata.so in a simple program like above work fine for me. My more complicated, real-world use case does consistently repro the bug before the patch but does not after. More digging required. Suggestions welcome! M On Thu, May 14, 2020 at 1:57 PM Simon Marchi wrote: > On 2020-05-14 1:48 p.m., mlimber wrote: > > Sure. Clearer repro steps: > > > > 1. Build an application linking to an SO that has no text segment. I > believe there is an SO attached to the bug ticket that will work. > > > > (My actual use case is a little complicated. I'm building a Qt 5.3 app > and Qt's libs have libicu*.so.52.2 as dependencies. Thus, I am indirectly > using libicudata.so.52.2, similar to what a recent commenter on the ticket > reported.) > > > > 2. Execute `gdb my_exe`. > > > > 3. Type 'r' at the gdb prompt to run. > > > > 4. Output from gdb 10: > > > > Starting program: [snip] > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > symfile.c:881: internal-error: sect_index_text not initialized > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Quit this debugging session? (y or n) > > > > Output from gdb 8.2: > > > > Starting program: [snip] > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > /build/gdb-q2KLFj/gdb-8.2/gdb/symfile.c:891: internal-error: > sect_index_text not initialized > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Quit this debugging session? (y or n) > > > > Is it legitimate to add binary files like an SO as part of the test, or > must I build all artifacts from source? If desired, I can attach the > offending SO to the ticket once my account is setup (waiting on setup > email). > > > > M > > Thanks. The best is to give a source snippet and compiler commands used > to build > it, so someone reading the commit message has everything they need to > reproduce the > issue if needed. It can also be good to mention which compiler version > (including if > it comes from a distro package) you use, because sometimes it matters. > > In this case, I'm guessing that compiling a simple shared library that has > only one > global variable and no code will be enough to reproduce the issue? > > For the test, we currently don't check in binary artifacts, they are all > generated > as part of the test. Grep for `gdb_compile_shlib` to see how to generate > a shared > library. > > I'm thinking that it would be useful to check in some binary artifacts, > but only > for really hard to reproduce cases. Like, gcc version x.y.z on this > distro with > this option generated something weird, and we want to make sure we don't > crash on > it. But we don't do that at the moment. > > Simon >