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

[mlimber <mlimber@gmail.com>]

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 <simark@simark.ca> 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
>