From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by sourceware.org (Postfix) with ESMTPS id AB8AF385DC0A for ; Fri, 15 May 2020 18:33:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AB8AF385DC0A Received: by mail-lf1-x142.google.com with SMTP id h26so2647856lfg.6 for ; Fri, 15 May 2020 11:33:20 -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=k+giNJXijHtPKv5edo7NDe/kQUAXexcnd7jdRhE7kxA=; b=r0nKQQUTf5stR68a9Qa10uQ70HIHypQRwdIYFjKLz5Lc46YHxfkWTi4g9UJ+Ou2oX1 /tPnCRz4X0ZVvpMfaq6kq+QDT7NtXCVE6MjI1x3kRfyyP3WoPbNi1oEbKOBwyTX8foAh VbseAqpUdYK7kvTxHlPQESR9U1Srj5bEB81mNqIbQoYmwT5WSrZPjIfGavxbTDnGs8aA Yzm02+xtUiIkwWmGCBmV8+WNBVL8afSzknon8FkCk5tHS0cn0eS9YBUy9Bmc5DLF5f+A w9Ygzxwv/NTuYMJ8UKqtpA/3/uLhI/HtxyNhAMBnSNL14zK1Jso4lkdMzQImycRjRsFS ydHA== X-Gm-Message-State: AOAM5326WlmE8y6RVUonz0j/zwe3IAVbANlNhOwC1wmXXf2JkrP/6fl7 MvlNrQS4DjolERFlnN5mL5nM4LkYo6EwbKO0qFRlkUC5 X-Google-Smtp-Source: ABdhPJzP6sotGvaneUYMoPtxxuxCYelmVzce9j0kkVsbVGHn+6oPgcTwBEPPcMG3erO9OCY7HTFmzFrXhu1ngno1GH4= X-Received: by 2002:ac2:48b2:: with SMTP id u18mr3133925lfg.122.1589567599283; Fri, 15 May 2020 11:33:19 -0700 (PDT) MIME-Version: 1.0 References: <072e4b2b-4d71-b343-c8ef-0edbc6ab6804@simark.ca> <59eeb6ee-1ab2-e5aa-000a-2fb6d522b8d0@simark.ca> In-Reply-To: <59eeb6ee-1ab2-e5aa-000a-2fb6d522b8d0@simark.ca> From: mlimber Date: Fri, 15 May 2020 14:33:08 -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=-1.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: Fri, 15 May 2020 18:33:31 -0000 Hrm. I've tried a number of smaller programs to repro this, including the steps in the comments using the attachment or building my own, X11, OpenGL, libicu tests, and also sample Qt apps that link `libicudata.so`. Alas, I cannot recreate it in small-ish form. I've tried various combinations of these on Ubuntu 14.04 x64 building with gcc 4.9 and also Ubuntu 20.04 x64 with gcc 9.3. I can reliably repro it with my full-scale Qt app, but I can't submit that. When I debug gdb itself, I see where it is going awry in my app -- with libicudata.so.52, which is a weird data-only library. I have updated the patch to be a little cleaner by handling this case earlier rather than at the end since that the problem is apparently that we have a non-zero starting address but no text section. Thus, I think it fits better like: --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -829,7 +829,8 @@ struct symfile_segment_data * ei->entry_point_p = 1; } else if (bfd_get_file_flags (objfile->obfd) & DYNAMIC - && bfd_get_start_address (objfile->obfd) != 0) + && bfd_get_start_address (objfile->obfd) != 0 + && objfile->sect_index_text != -1) { /* Some shared libraries may have entry points set and be runnable. There's no clear way to indicate this, so just check for values other than zero. */ ei->entry_point = bfd_get_start_address (objfile->obfd); ei->entry_point_p = 1; } else { - /* Examination of non-executable.o files. Short-circuit this stuff. */ + /* Examination of non-executable.o files or shared library with + no text segment. Short-circuit this stuff. */ ei->entry_point_p = 0; } The issue description also says that one needs >2 segments, but I don't see where that comes in yet. Perhaps that's what I'm missing in trying to repro it? I'm willing to keep trying. Can you recommend any way for me to repro the issue in a small test case? Thanks! M On Thu, May 14, 2020 at 3:28 PM Simon Marchi wrote: > On 2020-05-14 3:12 p.m., mlimber via Gdb-patches wrote: > > 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 > > If you can make a reproducer that uses Qt, that's a good start. Then we > can > track down what's special about this use case, and try to make a reproducer > that doesn't use it. > > But for the record, I was able to reproduce the crash using the > instructions > in the bug. Keith (comment 3) did too. > > Simon >