https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #26 from Thomas Neumann ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #25 from Carlos Galvez ---
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;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #24 from Florian Weimer ---
(With the missing ; added, of course.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #23 from Florian Weimer ---
(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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #22 from Carlos Galvez ---
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #21 from Thomas Neumann ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #19 from Thomas Neumann ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #18 from Carlos Galvez ---
Thanks for the investigation! To clarify: my last reproducible example does not
use gold, instead it uses the default GNU ld version 2.38.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #17 from Thomas Neumann ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Thomas Neumann changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #15 from Carlos Galvez ---
Created attachment 55261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55261=edit
Reproducible example nvinfer
Attaching (hopefully) reproducible example as a tarball, containing:
- download.sh:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #14 from Thomas Neumann ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Richard Biener changed:
What|Removed |Added
CC||tneumann at users dot
sourceforge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #12 from Carlos Galvez ---
I just tested latest and greatest trunk (git commit
2415024e0f81f8c09bf08f947c790b43de9d0bbc) and the problem persists. Slightly
different line numbers but essentially same backtrace:
#0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #11 from Andrew Pinski ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #10 from Carlos Galvez ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #9 from Richard Biener ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #8 from Carlos Galvez ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #7 from Richard Biener ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #6 from Carlos Galvez ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Carlos Galvez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #4 from Carlos Galvez ---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libgcc
--- Comment #2 from Andrew
25 matches
Mail list logo
