From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 348BF3851C10 for ; Thu, 14 May 2020 17:57:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 348BF3851C10 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9F1CF1E79B; Thu, 14 May 2020 13:57:25 -0400 (EDT) Subject: Re: [PATCH] [PR 25678] gdb crashes with "internal-error: sect_index_text not initialized" when .text To: mlimber Cc: gdb-patches@sourceware.org References: <072e4b2b-4d71-b343-c8ef-0edbc6ab6804@simark.ca> From: Simon Marchi Message-ID: Date: Thu, 14 May 2020 13:57:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, 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 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 17:57:27 -0000 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