Created attachment 6394 [details] Binary which causes gdb to crash on load (linux/x86_64) I have a binary which makes fairly heavy use of C++11 features including variadic templates, decltype, etc. GDB segfaults on startup when "reading symbols" from this binary. I tried to narrow the problem down by progressively commenting out code until the problem went away, but although commenting out enough code fixed the problem, it didn't seem to correlate with any one piece of code. My guess is that GDB is running out of space in some fixed-size table. My code perhaps triggers the problem because I am using lots of deeply-nested templates leading to very long symbol names. So, I am just attaching the whole binary. You don't have to run the binary, just try to load it in gdb. (The code can be found at kentons-code.googlecode.com, but it's complicated to build, undocumented, and generally incomprehensible.) The problem occurs in Ubuntu's gdb 4.7 as well as built-from-source gdb 4.7.1. Happy to provide more info if you can tell me what would be useful. :) $ uname -a Linux megaman 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ gcc-4.7 --version gcc-4.7 (Ubuntu/Linaro 4.7.0-7ubuntu3) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gdb --version GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. $ gdb crashgdb GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /home/kenton/code/crashgdb...Segmentation fault (core dumped)
Ugh, when I said gdb 4.7/4.7.1 I of course meant gdb 7.4/7.4.1...
It's a bug in the demangler. Valgrind shows: barimba. echo _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRNS2_16TokenParserInputEE_EEEEEINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesizedEEEE6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionEEEEEEEEENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEEEEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_EEEEENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipEEEEESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EEEEELb0EEEEEENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeEEEEOS1F_DpOS1L_ | valgrind --num-callers=50 ~/gnu/archer/build/libiberty/demangle ==2911== Memcheck, a memory error detector ==2911== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2911== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2911== Command: /home/tromey/gnu/archer/build/libiberty/demangle ==2911== ==2911== Conditional jump or move depends on uninitialised value(s) ==2911== at 0x405925: d_find_pack (cp-demangle.c:3697) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x405A25: d_find_pack (cp-demangle.c:3731) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x4059FD: d_find_pack (cp-demangle.c:3728) ==2911== by 0x407D49: d_print_comp (cp-demangle.c:4659) ==2911== by 0x406F53: d_print_comp (cp-demangle.c:4336) ==2911== by 0x406FEC: d_print_comp (cp-demangle.c:4348) ==2911== by 0x406F53: d_print_comp (cp-demangle.c:4336) ==2911== by 0x406FEC: d_print_comp (cp-demangle.c:4348) ==2911== by 0x406171: d_print_comp (cp-demangle.c:3947) ==2911== by 0x406B0B: d_print_comp (cp-demangle.c:4206) ==2911== by 0x405F8E: d_print_comp (cp-demangle.c:3894) ==2911== by 0x4057A0: cplus_demangle_print_callback (cp-demangle.c:3611) ==2911== by 0x408FE6: d_demangle_callback (cp-demangle.c:5240) ==2911== by 0x40903B: d_demangle (cp-demangle.c:5261) ==2911== by 0x4090A5: cplus_demangle_v3 (cp-demangle.c:5418) ==2911== by 0x409601: main (cp-demangle.c:5667) ==2911==
Submitted a patch.
Fixed. But note if you are checking out from the gdb cvs repository, you will have to wait until the file is sync'd from gcc svn. The change you want is this one, from libiberty: 2012-05-22 Tom Tromey <tromey@redhat.com> http://sourceware.org/bugzilla/show_bug.cgi?id=14065 * testsuite/demangle-expected: Add regression test. * cp-demangle.c (d_find_pack): Return NULL for DEMANGLE_COMPONENT_UNNAMED_TYPE.
Thanks for the fix!