GDB-Fehler "cp_search_static_and_baseclasses"

Question

Ich benutze STM32 Workbench (Eclipse-basierte IDE) und ich habe einen Arbeitsbereich mit ein paar C++ statische Bibliotheken und 2 C++ Anwendungen, alle mit der STM32F4 MCU C++ - Anwendung oder statische Lib-Vorlage.

Meine erste Anwendung lief gut und ich begann die zweite. Diese Projektvorlagen fügen eine main.c mit einer infinite Schleife hinzu, unabhängig von der Sprache. Wenn ich versuche, die main.c alles zu debuggen ist in Ordnung, aber wenn ich den Namen der Datei main.cpp ändern (Ich brauche, dass C++ Klassen innerhalb verwenden) GDB stoppt, bevor Debug mit dem Fehler:

/home/build/work/GCC-5-0-build/src/gdb/gdb/cp-namespace.c:343: internal-error: cp_search_static_and_baseclasses: Assertion `name[prefix_len + 1] == ':'' failed.

Vor dass ich viele "No source file named" -Fehler für Dateien habe, die nur für meine erste Anwendung benötigt werden, auch für die main.cpp der ersten Anwendung.

I STM32 Workbench 1.9 in Eclipse Mars bin mit 4.5.2 mit GDB 7.10.1

EDIT

ich davon ausgegangen, dass die "keine Quelldatei namens" Fehler zeigt an, dass vielleicht GDB sein wird geladen mit den falschen Dateien, so habe ich versucht, einen neuen Arbeitsbereich mit nur den Projekten für diese Anwendung benötigt und alles funktioniert. Trotzdem wäre es schön, alle Projekte im selben Arbeitsbereich zu haben. Ich bin mir nicht sicher, ob lib-Projekte, die in zwei Arbeitsbereichen geöffnet werden, schädlich sein können.

Answer 1

Ich habe Informationen zu beitragen, obwohl keine vollständige Antwort. Ich würde als Kommentar hinzufügen, aber ich habe nicht den Vertreter. Punkte noch zu tun.

Ich kann zu main ausführen, aber wenn ich einen Haltepunkt setze, sehe ich das gleiche Verhalten wie das OP. Meine Version von gdb ist 7.11

Ich habe festgestellt, dass, wenn ich ssh vom Host zum Ziel und starten gdb, ich nicht beobachten das Verhalten - ich kann Breakpoints setzen, kein Problem. Ich sehe nur das schlechte Verhalten, wenn ich dies durch Eclipse mache. Der einzige Unterschied zwischen den zwei Szenarien, den ich sehe, ist, dass wenn gdb über Eclipse gestartet wird (via ssh), es die --interpreter mi2 Option verwendet.

Vielleicht eine Idee für ein Work-around dies löst ...

Answer 2

Ich hatte ein ähnliches Problem in Eclipse mit GDB abstürzt. Ich hatte einige alte Haltepunkte im Eclipse-Arbeitsbereich aktiviert. Nach dem Entfernen dieser Haltepunkte aus anderen Projekten wurde das Problem behoben.