Re: [PATCH] [PR 25678] gdb crashes with "internal-error: sect_index_text not initialized" when .text

[Simon Marchi <simark@simark.ca>]

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