Bug 16593 - gdb segfaults when reading symbol table
Summary: gdb segfaults when reading symbol table
Status: RESOLVED DUPLICATE of bug 16752
Alias: None
Product: gdb
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.7
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-15 02:59 UTC by jeremycong
Modified: 2014-03-28 21:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jeremycong 2014-02-15 02:59:55 UTC
I have had some trouble coming up with a small example that reproduces this error, but I encounter this with an executable built from the project Selene (https://github.com/jeremyong/Selene).

Compile with

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make

Afterwards, attempts to run gdb ./test fail with

Reading symbols from ./test...[1]    15240 segmentation fault (core dumped)  gdb ./test

This does NOT occur when the project is compiled with clang++ and run with lldb.
Comment 1 jeremycong 2014-02-15 03:17:11 UTC
Ah I neglected to mention that I am running 64 bit Linux and compiling the program with gcc 4.8.2 20140206 with the flags -std=c++11 and -g.
Comment 2 Keith Seitz 2014-03-28 21:08:36 UTC
This is also c++/16752 and/or c++/14963. The problematic mangled name is:

_ZNSt9_Any_data9_M_accessIPZN3sel8Selector6SetObjI3FooJPKcMS4_FviEEEEvRT_DpT0_EUlvE_EESA_v

Prior to commit 9548bbede51868a9a780d7d21ae16ac13e8bdf9b (2013-10-25 to cp-demangle.c in libiberty), gdb would report:

$ ./gdb -nx -q -ex "set lang c++" -ex "maint demangle _ZNSt9_Any_data9_M_accessIPZN3sel8Selector6SetObjI3FooJPKcMS4_FviEEEEvRT_DpT0_EUlvE_EESA_v"
void sel::Selector::SetObj<Foo, char const*, void (Foo::*)(int)>(Foo&, char const*, void (Foo::*)(int))::{lambda()#1}*& std::_Any_data::_M_access<void sel::Selector::SetObj<Foo, char const*, void (Foo::*)(int)>(Foo&, char const*, void (Foo::*)(int))::{lambda()#1}*>()

*** This bug has been marked as a duplicate of bug 16752 ***