https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
--- Comment #3 from Jeff Garrett <jeff at jgarrett dot org> --- That's such a good point about the local types in general. Considering that the gdb python API seems to prefer readable names, e.g. for lookup, and those are not standard nor unique, might it be perhaps preferable to avoid going through the regex to get the manager type, and from that the contained type? Something like this? mgr = self.val['_M_manager'] if mgr != 0: # cast to uintptr_t doesn't seem to be necessary func = gdb.block_for_pc(long(mgr)) if not func: raise ValueError("Invalid function pointer in %s" % self.typename) self.contained_type = gdb.lookup_symbol('_Tp', func)[0].type valptr = None mgrfuncname = func.function.name if mgrfuncname.startswith('{0}::_Manager_internal'.format(self.typename)): valptr = self.val['_M_storage']['_M_buffer'].address elif mgrfuncname.startswith('{0}::_Manager_external'.format(self.typename)): valptr = self.val['_M_storage']['_M_ptr'] else: raise ValueError("Unknown manager function in %s" % self.typename) contained_value = valptr.cast(self.contained_type.pointer()).dereference() We can lookup the symbol for the formal template parameter of the manager by its name ('_Tp') in the context of the block for the _S_manage function. I'm not an expert in any of this, so there may be a reason this is not preferable. It does seem to work with some fundamental types and std::string as well (with no magic to handle the typedef). It still fails in the multiple local lambdas case... But that seems like an easier to solve problem, because I believe the DWARF debugging has enough information to know which lambda is _Tp in each of the instantiations, and gdb is just getting confused. I think it should work in principle.