[Bug c++/109712] New: Segmentation fault in linear_search_fdes

[Bug c++/109712] New: Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

            Bug ID: 109712
           Summary: Segmentation fault in linear_search_fdes
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Created attachment 54978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54978&action=edit
Reproducible example

Hi!

We are bumping our GCC installation from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
07c52d1eec9671af92b7ce977b469f13a87887ad and are now getting a segmentation
fault when an exception is thrown, gdb points at "linear_search_fdes". Here's
the backtrace:

Thread 1 "a.out" received signal SIGSEGV, Segmentation fault.
linear_search_fdes (ob=0x7fffffffd690, this_fde=0x0, pc=0x404248 <foo()+50>) at
../../../gcc/libgcc/unwind-dw2-fde.c:969
969     ../../../gcc/libgcc/unwind-dw2-fde.c: No such file or directory.
(gdb) bt
#0  linear_search_fdes (ob=0x7fffffffd690, this_fde=0x0, pc=0x404248
<foo()+50>) at ../../../gcc/libgcc/unwind-dw2-fde.c:969
#1  0x00007ffff77c1e11 in find_fde_tail (dbase=18446744073709383432,
bases=0x7fffffffd8e8, hdr=0x4aaa34, pc=4211272) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:519
#2  _Unwind_Find_FDE (pc=<optimized out>, bases=bases@entry=0x7fffffffd8e8) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:573
#3  0x00007ffff77bd4aa in uw_frame_state_for (context=0x7fffffffd840,
fs=0x7fffffffd930) at ../../../gcc/libgcc/unwind-dw2.c:1005
#4  0x00007ffff77beefd in _Unwind_RaiseException (exc=0xcfc390) at
../../../gcc/libgcc/unwind.inc:104
#5  0x00007ffff7bced8a in __cxa_throw () from
/home/s0000069/src/src/bazel-src/external/gcc_trunk_x86_64_linux/usr/lib64/libstdc++.so.6
#6  0x0000000000404249 in foo () at ../main.cpp:8
#7  0x00000000004042a7 in main () at ../main.cpp:18

I attach a reproducible example that I have tested on Ubuntu 20.04, it will
download dependencies and build the example project. It expects a "GCC_BASE"
variable to be set pointing to the base GCC installation.

I have made the following observations, so I'm not sure the problem is GCC, but
I thought nevertheless to share it in case someone has a good intuition for
what could be happening. If this is not the right forum please let me know
where I should ask!

* The problem happens only when linking libcudart_static.a. If I think
libcudart.so it's fine. I have asked this question at the Nvidia forums as
well, awaiting reply.
* The problem happens only when throwing exceptions.
* The problem happens only when using the Gold linker.
* The problem happens only if I use the GCC trunk's libstdc++.so and
libgcc_s.so at runtime (via rpath). If I use the Ubuntu 20.04 system-installed
libraries, it runs fine.

Thank you for your time!

[Bug c++/109712] Segmentation fault in linear_search_fdes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Does libcudart_static.a by chance contain any symbols from the libgcc runtime
(of an old toolchain)?

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libgcc

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>* The problem happens only when using the Gold linker.

This could also point to a bug with the GOLD linker. I am not sure if the gold
linker is even maintained these days or well enough tested.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-05-03

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>find . -iname "*.deb" -exec dpkg-deb -x {} cuda \;

This won't work on non-debian based targets. IIRC debs are archives which
contain two tar files which you can just use ar followed by tar to extract the
files instead of using dpkg-deb.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #4 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
> Does libcudart_static.a by chance contain any symbols from the libgcc runtime

I'm not sure, do you know how I could check that (I'm pretty n00b on these
things :)). What I know is that libcudart.so does not have a dependency to
neither libstdc++.so nor libgcc_s.so, only to libc, libdl, libpthread, librt.

> This could also point to a bug with the GOLD linker. 

Indeed switching to BFD also solves the problem. I will try with LLD as well!

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Carlos Galvez <carlosgalvezp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Works with LLD as well, so it seems likely a Gold bug. I wasn't aware is was no
longer well maintained, good to know! Thanks again for your help :)

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #6 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Hi again!

I realized there is still one more problem missing, so I suspect the linker was
not the only culprit. It does not segfault, but it gets stuck in an infinite
loop, once again when mixing exceptions and libcudart_static.a.

@Richard you mentioned:

> Does libcudart_static.a by chance contain any symbols from the libgcc runtime (of an old toolchain)?

Do you know how I could verify this? I'm pretty new when it comes to
troubleshooting these things.

My understanding is that libstdc++.so and libgcc_s.so are always backwards
compatible so using "the latest" ensures you can use the newest features and
also run older built code. Is there a flaw/pitfall in that reasoning?

Thanks!

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Carlos Galvez from comment #6)
> Hi again!
> 
> I realized there is still one more problem missing, so I suspect the linker
> was not the only culprit. It does not segfault, but it gets stuck in an
> infinite loop, once again when mixing exceptions and libcudart_static.a.
> 
> @Richard you mentioned:
> 
> > Does libcudart_static.a by chance contain any symbols from the libgcc runtime (of an old toolchain)?
> 
> Do you know how I could verify this? I'm pretty new when it comes to
> troubleshooting these things.
> 
> My understanding is that libstdc++.so and libgcc_s.so are always backwards
> compatible so using "the latest" ensures you can use the newest features and
> also run older built code. Is there a flaw/pitfall in that reasoning?

There were changes to the internal data structures of the unwinder so I
wondered if you somehow managed to mix unwinder parts of different versions.

You probably have a libgcc_eh.a file as part of your GCC install, you could
look for symbols this library provides in the NVIDIA static archives.

> Thanks!

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #8 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Upon closer inspection, it turns out we were building with GCC 7, but then
using libgcc_s.so.1 and libstdc++.so.6 from GCC trunk at runtime (via
LD_LIBRARY_PATH). Building with GCC trunk instead solves the segfault I
described above.

In particular it seems the problem is libgcc_s.so.1 - if I use the system-wide 
one (older) instead of the one from GCC trunk, the problem goes away.

Is this expected though? My understanding was that libgcc_s and libstdc++ are
backwards compatible, i.e. I can always keep the latest one installed on my
system and I should be able to run applications linked against older libraries
(which is what is happening here). There's also symbol versioning so old
symbols are kept.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yes, using a newer libgcc_s.so.1 or libstdc++.so.6 should work fine - again,
unless we end up with mixing static/dynamic parts of the unwinder of different
versions.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #10 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Hi!

I've continued to look into this and am having a slightly different but
essentially same error with yet another Nvidia library, but this time is with a
pure shared library, "libnvinfer.so", which was compiled against GCC 7. Most
likely the library is statically linked against libcudart_static.a. The issue
is not solved using bfd or lld linker.

My program simply links against that library, which internally throws an
exception. I get a very similar backtrace:

#0  linear_search_fdes (ob=0x7fffffffd350, this_fde=0x0, pc=0x7fffdf4b6a69) at
../../../gcc/libgcc/unwind-dw2-fde.c:973
#1  0x00007fffdde1cde1 in find_fde_tail (dbase=2424076, bases=0x7fffffffd5a8,
hdr=0x7ffff690ca70, pc=140736939649641) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:519
#2  _Unwind_Find_FDE (pc=<optimized out>, bases=bases@entry=0x7fffffffd5a8) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:573
#3  0x00007fffdde1847a in uw_frame_state_for (context=0x7fffffffd500,
fs=0x7fffffffd5f0) at ../../../gcc/libgcc/unwind-dw2.c:1005
#4  0x00007fffdde19ecd in _Unwind_RaiseException (exc=0x904320) at
../../../gcc/libgcc/unwind.inc:104
#5  0x00007fffde2b7e6a in __cxa_throw () from /path/to/usr/lib64/libstdc++.so.6
#6  0x00007fffdf4b6a6a in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#7  0x00007fffdf4c21b5 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#8  0x00007fffdfbddf02 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#9  0x00007fffdf42a118 in createInferBuilder_INTERNAL () from
/path/to/nvinfer/lib/libnvinfer.so.8
#10 0x0000000000401163 in nvinfer1::(anonymous namespace)::createInferBuilder
(logger=...) at nvinfer/include/NvInfer.h:9093
#11 0x0000000000401182 in main () at main.cpp:13


So the library was compiled with GCC 7 and has a dependency on libstdc++.so.6.
Via LD_LIBRARY_PATH, I run my executable using GCC trunk (14)'s libstdc++.so.6.

Now, I try to see if "libnvinfer_static.a" uses any symbol from "libgcc_eh.a",
by doing:

- Run "nm libgcc_eh.a" and store a list of all "T" or "t" symbols.
- Run "nm libnvinfer_static.a" and store a list of all "U" symbols.
- Compute the intersection between those two lists.

This results in that "libnvinfer_static.a" only uses 1 symbol from libgcc_eh.a:
_Unwind_Resume.

Is the above test procedure correct to determine the symbols used from
libgcc_eh.a?

How come linking a pure shared library such as libnvinfer.so would lead to
mixing types from different versions of libgcc_eh.a, i.e. how could those
internal changes leak outside the shared library boundaries? 

After all this comes from __cxa_throw() from libstdc++.so.6, which is a
versioned symbol. Shouldn't that function get a new symbol version if there's
an ABI incompatible change?

Thank you for your time and help, really appreciated!

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Carlos Galvez from comment #10)
> So the library was compiled with GCC 7 and has a dependency on
> libstdc++.so.6. Via LD_LIBRARY_PATH, I run my executable using GCC trunk
> (14)'s libstdc++.so.6.

Was the trunk before or after r14-1515-g38e88d41f50d844f1404 ? Can you try
building the trunk again?

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #12 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
I just tested latest and greatest trunk (git commit
2415024e0f81f8c09bf08f947c790b43de9d0bbc) and the problem persists. Slightly
different line numbers but essentially same backtrace:

#0  linear_search_fdes (ob=0x7fffffffd1d0, this_fde=0x0, pc=0x7fffdf4b6624) at
../../../gcc/libgcc/unwind-dw2-fde.c:977
#1  0x00007fffdde1ce51 in find_fde_tail (dbase=2424076, bases=0x7fffffffd428,
hdr=0x7ffff690ca70, pc=140736939648548) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:519
#2  _Unwind_Find_FDE (pc=<optimized out>, bases=bases@entry=0x7fffffffd428) at
../../../gcc/libgcc/unwind-dw2-fde-dip.c:573
#3  0x00007fffdde184aa in uw_frame_state_for (context=0x7fffffffd380,
fs=0x7fffffffd470) at ../../../gcc/libgcc/unwind-dw2.c:1005
#4  0x00007fffdde19efd in _Unwind_RaiseException (exc=0x1d994fb0) at
../../../gcc/libgcc/unwind.inc:104
#5  0x00007fffde2b808a in __cxa_throw () from
/path/to/gcc/usr/lib64/libstdc++.so.6
#6  0x00007fffdf4b6625 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#7  0x00007fffdf0f5df3 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#8  0x00007fffe1bff20b in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#9  0x00007fffdf428c3f in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#10 0x00007fffdf4297db in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#11 0x00007fffdf429ef7 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8
#12 0x00007fffdf42a17d in createInferBuilder_INTERNAL () from
/path/to/nvinfer/lib/libnvinfer.so.8
#13 0x0000000000401163 in nvinfer1::(anonymous namespace)::createInferBuilder
(logger=...) at nvinfer/include/NvInfer.h:9093
#14 0x0000000000401182 in main () at main.cpp:13

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tneumann at users dot sourceforge.
                   |                            |net
         Resolution|INVALID                     |---
             Status|RESOLVED                    |REOPENED

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Let's re-open this as it seems it needs more analysis.  Thomas might also know
of relevant bugs that have been fixed meanwhile and maybe has better
understanding of how things could break here.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #14 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
I cannot reproduce the problem, but admittedly I used a newer Ubuntu version. I
tried compiling it with gcc 7.5.0, linking it with gold 1.16, and using the gcc
version you specified (07c52d1eec9) for the shared library without problems.

Can you attach the a.out that you generate? This will hopefully allow me to
reproduce the problem.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #15 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Created attachment 55261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55261&action=edit
Reproducible example nvinfer

Attaching (hopefully) reproducible example as a tarball, containing:

- download.sh: script to download an unpack the Nvidia dependencies.
- test.sh: script to build and test the application. It expects a GCC_BASE
environment variable existing pointing to the base GCC trunk
installation/build.
- a.out: the compiled binary.

This has been tested on Ubuntu 22.04.

Thank you for your time!

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Thomas Neumann <tneumann at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #16 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
e724b04

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #17 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
The bug was introduced by gcc commit e724b04. It avoids calls to
read_encoded_value_with_base for performance reasons, but unfortunately this
causes the variable eh_frame to be uninitialized if the fast path is taken in
find_fde_tail (unwind-dw2-fde-dip.c).

This is only visible with the gold linker because gold does not provide a
conveniently organized unwind table, with causes the code to fall back to the
slow linear_search_fdes, which uses the (uninitialized) eh_frame value.

Florian, can you fix that? For me it is not obvious how to compute the correct
eh_frame value without calling read_encoded_value_with_base, but you probably
know how to do that.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #18 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Thanks for the investigation! To clarify: my last reproducible example does not
use gold, instead it uses the default GNU ld version 2.38.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #19 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
Hm, then I don't know how we end up with the non-regular table content. The
code checks for hdr->fde_count_enc != DW_EH_PE_omit, and that is false in the
executable that you provided.

But regardless of why the table is strange, the bug is definitively caused by
the uninitialized eh_frame variable in find_fde_tail. It must be set in the
fast path, too.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at gcc dot gnu.org

--- Comment #20 from Florian Weimer <fw at gcc dot gnu.org> ---
Thanks for looking into this, Thomas.  I suspect it's a simple typo, which
happens not to matter in many cases because both dbase and eh_frame are unused:

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 6223f5f18a2..b7b09d584c8 100644
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -404,7 +404,7 @@ find_fde_tail (_Unwind_Ptr pc,
       signed value __attribute__ ((mode (SI)));
       memcpy (&value, p, sizeof (value));
       p += sizeof (value);
-      dbase = value;           /* No adjustment because pcrel has base 0.  */
+      eh_frame = value;                /* No adjustment because pcrel has base
0.  */
     }
   else
     p = read_encoded_value_with_base (hdr->eh_frame_ptr_enc,

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #21 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
It must be something more complex. value is small here (more precisely: 1888 in
the crashes later), which is not a valid pointer address. We probably have to
add this to some base pointer? But it is not obvious to me to which one.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #22 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Indeed it's an uninitialized read according to valgrind:

==15475== Use of uninitialised value of size 8
==15475==    at 0x1E81C2E9: base_from_object (unwind-dw2-fde.c:319)
==15475==    by 0x1E81C2E9: linear_search_fdes (unwind-dw2-fde.c:975)
==15475==    by 0x1E81CE50: find_fde_tail (unwind-dw2-fde-dip.c:519)
==15475==    by 0x1E81CE50: _Unwind_Find_FDE (unwind-dw2-fde-dip.c:573)
==15475==    by 0x1E8184A9: uw_frame_state_for (unwind-dw2.c:1005)
==15475==    by 0x1E819EFC: _Unwind_RaiseException (unwind.inc:104)
==15475==    by 0x1E2B8089: __cxa_throw (in
/path/to/gcc/usr/lib64/libstdc++.so.6.0.32)

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #23 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Thomas Neumann from comment #21)
> It must be something more complex. value is small here (more precisely: 1888
> in the crashes later), which is not a valid pointer address. We probably
> have to add this to some base pointer? But it is not obvious to me to which
> one.

read_encoded_value_with_base has this:

          result += ((encoding & 0x70) == DW_EH_PE_pcrel
                     ? (_Unwind_Internal_Ptr) u : base);

u is the original read pointer as far as I can see. So it looks like it should
look like this:

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 6223f5f18a2..5a6352227cc 100644
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -403,8 +403,8 @@ find_fde_tail (_Unwind_Ptr pc,
         BFD ld generates.  */
       signed value __attribute__ ((mode (SI)));
       memcpy (&value, p, sizeof (value));
+      eh_frame = p + value
       p += sizeof (value);
-      dbase = value;           /* No adjustment because pcrel has base 0.  */
     }
   else
     p = read_encoded_value_with_base (hdr->eh_frame_ptr_enc,

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #24 from Florian Weimer <fw at gcc dot gnu.org> ---
(With the missing ; added, of course.)

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #25 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Perhaps this is a stupid comment, but isn't "ob.s.b.encoding" uninitialized?

  /* inside find_fde_tail */
  struct object ob;

  ...

  ob.pc_begin = NULL;
  ob.tbase = NULL;
  ob.dbase = (void *) dbase;
  ob.u.single = (fde *) eh_frame;
  ob.s.i = 0;
  ob.s.b.mixed_encoding = 1;  /* Need to assume worst case.  */
  const fde *entry = linear_search_fdes (&ob, (fde *) eh_frame, (void *) pc);

Above, only "ob.s.b.mixed_encoding" is set, not "ob.s.b.encoding".

After that, "linear_search_fdes" expects that it's set:

static const fde *
linear_search_fdes (struct object *ob, const fde *this_fde, void *pc)
{
  const struct dwarf_cie *last_cie = 0;
  int encoding = ob->s.b.encoding;
  _Unwind_Ptr base = base_from_object (ob->s.b.encoding, ob);

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #26 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
(In reply to Florian Weimer from comment #23)
> 
> u is the original read pointer as far as I can see. So it looks like it
> should look like this:
> 
> diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
> index 6223f5f18a2..5a6352227cc 100644
> --- a/libgcc/unwind-dw2-fde-dip.c
> +++ b/libgcc/unwind-dw2-fde-dip.c
> @@ -403,8 +403,8 @@ find_fde_tail (_Unwind_Ptr pc,
>  	 BFD ld generates.  */
>        signed value __attribute__ ((mode (SI)));
>        memcpy (&value, p, sizeof (value));
> +      eh_frame = p + value
>        p += sizeof (value);
> -      dbase = value;		/* No adjustment because pcrel has base 0.  */
>      }
>    else
>      p = read_encoded_value_with_base (hdr->eh_frame_ptr_enc,


that seems to be correct, the test case succeeds with that patch.

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.2
           Priority|P3                          |P1
            Summary|Segmentation fault in       |[13/14 Regression]
                   |linear_search_fdes          |Segmentation fault in
                   |                            |linear_search_fdes

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-linux-gnu            |
           Assignee|unassigned at gcc dot gnu.org      |fw at gcc dot gnu.org
             Status|REOPENED                    |ASSIGNED

--- Comment #27 from Florian Weimer <fw at gcc dot gnu.org> ---
Patch posted:

[PATCH] libgcc: Fix eh_frame fast path in find_fde_tail
<https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620731.html>

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #28 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
The proposed patch fixes the issue on our side, thank you!

I realize my comment about doesn't make sense - I was mixing unions in C (where
type punning is fine) and C++ (UB). But then I don't understand why valgrind
would point at that variable as uninitialized...

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #29 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
*my comment about uninitialized "ob.s.b.encoding".

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Florian Weimer <fw@gcc.gnu.org>:

https://gcc.gnu.org/g:49310a993308492348119f4033e4db0bda4fe46a

commit r14-1614-g49310a993308492348119f4033e4db0bda4fe46a
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Jun 6 11:01:07 2023 +0200

    libgcc: Fix eh_frame fast path in find_fde_tail

    The eh_frame value is only used by linear_search_fdes, not the binary
    search directly in find_fde_tail, so the bug is not immediately
    apparent with most programs.

    Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc:
    Special-case BFD ld unwind table encodings in find_fde_tail").

    libgcc/

            PR libgcc/109712
            * unwind-dw2-fde-dip.c (find_fde_tail): Correct fast path for
            parsing eh_frame.

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #31 from Florian Weimer <fw at gcc dot gnu.org> ---
Will propose a backport to 13 in ~2 weeks.

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #32 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Florian Weimer from comment #31)
> Will propose a backport to 13 in ~2 weeks.

Any news on the backport? There is aim to release GCC 13.2.0 at the end of
July.

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #33 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #32)
> (In reply to Florian Weimer from comment #31)
> > Will propose a backport to 13 in ~2 weeks.
> 
> Any news on the backport? There is aim to release GCC 13.2.0 at the end of
> July.

I managed to produce a warning regression. I should have time this week to fix
that, and do the backport this week.

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
You have until Thursday for the backport which is when we want to do 13.2 RC1

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #35 from Florian Weimer <fw at gcc dot gnu.org> ---
Backport posted, along with the warning fix:

[PATCH releases/gcc-13 1/2] libgcc: Fix eh_frame fast path in find_fde_tail
<https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624804.html>

[PATCH releases/gcc-13 2/2] libgcc: Fix -Wint-conversion warning in
find_fde_tail
<https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624805.html>

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Florian Weimer <fw@gcc.gnu.org>:

https://gcc.gnu.org/g:7302f8a2fa2f95252b32de2dc826591e75230662

commit r13-7582-g7302f8a2fa2f95252b32de2dc826591e75230662
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Jun 6 11:01:07 2023 +0200

    libgcc: Fix eh_frame fast path in find_fde_tail

    The eh_frame value is only used by linear_search_fdes, not the binary
    search directly in find_fde_tail, so the bug is not immediately
    apparent with most programs.

    Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc:
    Special-case BFD ld unwind table encodings in find_fde_tail").

    libgcc/

            PR libgcc/109712
            * unwind-dw2-fde-dip.c (find_fde_tail): Correct fast path for
            parsing eh_frame.

    (cherry picked from commit 49310a993308492348119f4033e4db0bda4fe46a)

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #37 from Florian Weimer <fw at gcc dot gnu.org> ---
Backported to 13, the only impacted release.