Created attachment 7490 [details] The binary on which gdb crash GDB crash when trying to parse the symbols of the attached binary. The backtrace indicate a stack overflow, probably a infinite recursion : #0 0x00000000006f7536 in ?? () #1 0x00000000006f9e67 in ?? () #2 0x00000000006fa561 in ?? () #3 0x00000000006f6c4c in ?? () #4 0x00000000006f76d7 in ?? () #5 0x00000000006f7727 in ?? () #6 0x00000000006f79f9 in ?? () #7 0x00000000006f78ef in ?? () #8 0x00000000006f79f9 in ?? () #9 0x00000000006f6e93 in ?? () #10 0x00000000006f84b5 in ?? () #11 0x00000000006fa59e in ?? () #12 0x00000000006f6c4c in ?? () #13 0x00000000006f76d7 in ?? () #14 0x00000000006f7727 in ?? () #15 0x00000000006f79f9 in ?? () #16 0x00000000006f78ef in ?? () #17 0x00000000006f79f9 in ?? () #18 0x00000000006f6e93 in ?? () #19 0x00000000006f84b5 in ?? () #20 0x00000000006fa59e in ?? () #21 0x00000000006f6c4c in ?? () #22 0x00000000006f76d7 in ?? () #23 0x00000000006f7727 in ?? () #24 0x00000000006f79f9 in ?? () #25 0x00000000006f78ef in ?? () #26 0x00000000006f79f9 in ?? () #27 0x00000000006f6e93 in ?? () #28 0x00000000006f84b5 in ?? () #29 0x00000000006fa59e in ?? () #30 0x00000000006f6c4c in ?? () #31 0x00000000006f76d7 in ?? () #32 0x00000000006f7727 in ?? () #33 0x00000000006f79f9 in ?? () #34 0x00000000006f78ef in ?? () #35 0x00000000006f79f9 in ?? () #36 0x00000000006f6e93 in ?? () #37 0x00000000006f84b5 in ?? () #38 0x00000000006fa59e in ?? () #39 0x00000000006f6c4c in ?? () #40 0x00000000006f76d7 in ?? () #41 0x00000000006f7727 in ?? () #42 0x00000000006f79f9 in ?? () #43 0x00000000006f78ef in ?? () #44 0x00000000006f79f9 in ?? () #45 0x00000000006f6e93 in ?? () #46 0x00000000006f84b5 in ?? () #47 0x00000000006fa59e in ?? () #48 0x00000000006f6c4c in ?? () #49 0x00000000006f76d7 in ?? () #50 0x00000000006f7727 in ?? () #51 0x00000000006f79f9 in ?? () #52 0x00000000006f78ef in ?? ()
I chased this down a tiny bit... While there is another outstanding bug wrt to symbol demangling in libiberty (see c++/14963), this particular failure is actually caused by a different patch: commit 9548bbede51868a9a780d7d21ae16ac13e8bdf9b Author: gary <gary@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Fri Oct 25 13:56:51 2013 +0000 libiberty/ 2013-10-25 Gary Benson <gbenson@redhat.com> * cp-demangle.c (struct d_saved_scope): New structure. (struct d_print_info): New fields saved_scopes and num_saved_scopes. (d_print_init): Initialize the above. (d_print_free): New function. (cplus_demangle_print_callback): Call the above. (d_copy_templates): New function. (d_print_comp): New variables saved_templates and need_template_restore. [DEMANGLE_COMPONENT_REFERENCE, DEMANGLE_COMPONENT_RVALUE_REFERENCE]: Capture scope the first time the component is traversed, and use the captured scope for subsequent traversals. * testsuite/demangle-expected: Add regression test. The symbol which causes the crash is: _ZNSt9_Any_data9_M_accessIPZN13ThreadManager7newTaskIRSt5_BindIFSt7_Mem_fnIM5DiaryFivEEPS5_EEIEEESt6futureINSt9result_ofIFT_DpT0_EE4typeEEOSF_DpOSG_EUlvE_EERSF_v
It's highly likely this is a duplicate of bug 14963.
To clarify, it's highly likely this is a duplicate of the reopened part of bug 14963 (from comment 16 onwards) in that this failure is likely to have the same cause as the failures reorted there.
*** Bug 16593 has been marked as a duplicate of this bug. ***
*** Bug 16845 has been marked as a duplicate of this bug. ***
Hi, I'm also having this problem. In my case, I'm observing that the mangled string "_ZNSt9_Any_data9_M_accessIPZN6cereal18polymorphic_detail15getInputBindingINS1_16JSONInputArchiveEEENS1_6detail15InputBindingMapIT_E11SerializersERS7_jEUlPvRSt10unique_ptrIvNS5_12EmptyDeleterIvEEEE0_EESA_v" Seems to get stuck in an infinite loop, and after 6 flushes of the buffer to the growable buffer, that buffer looks like this" "cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cerea" I'm going to assume that there's a bug in the dc tree parser or walker? I'm very new to this and I guess my next step is to read the ABI and see what the correct demangling of that string should look like, that should give me some idea of where to look for where it goes off the rails.
(In reply to Adrian Cheater from comment #6) > Hi, I'm also having this problem. > > In my case, I'm observing that the mangled string > > "_ZNSt9_Any_data9_M_accessIPZN6cereal18polymorphic_detail15getInputBindingINS > 1_16JSONInputArchiveEEENS1_6detail15InputBindingMapIT_E11SerializersERS7_jEUl > PvRSt10unique_ptrIvNS5_12EmptyDeleterIvEEEE0_EESA_v" > > Seems to get stuck in an infinite loop, and after 6 flushes of the buffer to > the growable buffer, that buffer looks like this" > > "cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal: > :detail::InputBindingMap<cereal::JSONInputArchive>::Serializers > cereal::polymorphic_detail::getInputBinding<cerea" c++filt indicates that this should demangle to: cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::JSONInputArchive&, unsigned int)::{lambda(void*, std::unique_ptr<void, cereal::detail::EmptyDeleter<void> >&)#2}*& std::_Any_data::_M_access<cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::polymorphic_detail::getInputBinding<cereal::JSONInputArchive>(cereal::JSONInputArchive&, unsigned int)::{lambda(void*, std::unique_ptr<void, cereal::detail::EmptyDeleter<void> >&)#2}*>()
Adrian, it's likely the commit that "fixed" bug 14963 is what's causing this segfault, so I'd check that first. Also, be careful using c++filt as a reference, it uses the same code (libiberty) as GDB, but it's statically linked so there can be version skew. If one works and the other doesn't then that is the likely cause. I also don't know if c++filt is even correct in how it demangles these symbols. I had a fix that stopped the recursion (and hence the segfaults) but it also changed the demangled results, and I don't know C++ or demangling nearly well enough to say whether either demangled form is correct.
Patch mailed: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00404.html
Fix committed to GCC SVN: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210205