Summary: | gdb segfaults when loading symbols in C++11-enabled application | ||
---|---|---|---|
Product: | gdb | Reporter: | Georg Rudoy <0xd34df00d> |
Component: | c++ | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bap.fayol, gbenson, keiths, pedro |
Priority: | P2 | ||
Version: | 7.7 | ||
Target Milestone: | 7.10 | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | Somewhat minimal reproducing example. |
Description
Georg Rudoy
2014-05-17 17:49:33 UTC
Looks like another demangler crash. Uncertain if it exactly c++/16752, but it could be the same bug(s). Can you try the patch referenced in that bug? (In reply to Keith Seitz from comment #1) > Looks like another demangler crash. Uncertain if it exactly c++/16752, but > it could be the same bug(s). Can you try the patch referenced in that bug? The one in https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00404.html ? I'll try, but that'll take some time. In the meanwhile I've run the mangled strings from the test cases via c++filt, and nothing got stuck or crashed. Does it make sense or help a bit? Yes, that looks like the patch. If c++filt came pre-installed by your system, you're not likely to trigger the bug -- it is almost certainly using a different libiberty than the one bundled into gdb-binutils, but passing the system c++filt is very good supporting evidence to suggest that you're running into the same bug. Give the patch a try. (or just checkout gdb repo or download a snapshot) Yes, that's c++filt that came with system binutils package. Now I'm slightly confused. That's the patch for gdb then? If so, that's good, as I was going to recompile gcc/binutils. GCC is considered the master repository for libiberty. gdb-binutils contains a copy. So all you need to do is rebuild gdb. Great, thanks for the explanation! The patch didn't work, though. gdb still crashes with exactly the same backtrace. Georg, could you please rebuild GDB with this patch: http://tinyurl.com/k2c6mw4 It will catch the crash and print the offending symbol. Georg, alternatively can you supply more of the backtrace of a crash? I need to see the mangled symbol name. http://gbenson.net/?p=422 shows an example, frames 9-12 have the mangled symbol mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu" (In reply to Gary Benson from comment #8) > Georg, alternatively can you supply more of the backtrace of a crash? I > need to see the mangled symbol name. http://gbenson.net/?p=422 shows an > example, frames 9-12 have the mangled symbol mangled=0x7ffffac19ea0 > "_Z1-Av23*;cG~Wo2Vu" Thanks, that's much faster than rebuilding with a patch. The line in backtrace containing d_demangle_callback: #69765 0x000000000071e518 in d_demangle_callback (mangled=<optimized out>, mangled@entry=0xe01eb4 "_Z7ZipWithI7QStringS0_5QListZN4oral6detail16AdaptCreateTableI7AccountEES0_RKNS3_16CachedFieldsDataEEUlRKS0_SA_E_ET1_IDTclfp1_cvT__EcvT0__EEEERKT1_ISC_ERKT1_ISD_ET2_", options=259, callback=callback@entry=0x716e70 <d_growable_string_callback_adapter>, opaque=opaque@entry=0x7fffffffd550) at ./cp-demangle.c:5890 Confirmed and filed as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61233 gcc/demangler patch sent: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html Fixed, both master and 7.10 branch (IOW, fix will be part of 7.10.1) Closing. thank you for the information. https://www.vitrier-strasbourg.com |