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

[mlimber <mlimber@gmail.com>]

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