Programmempfangssignal SIGTRAP, Trace/Breakpoint-Trap

Lesezeit: 3 Minuten

Benutzer-Avatar
Zufallsblau

Ich debugge ein Stück (eingebettete) Software. Ich habe einen Haltepunkt für eine Funktion gesetzt, und aus irgendeinem Grund, sobald ich diesen Haltepunkt erreicht habe und continue Ich komme immer wieder auf die Funktion zurück (das ist eine Initialisierungsfunktion, die nur einmal aufgerufen werden sollte). Wenn ich den Haltepunkt entferne, und continueGDB sagt mir:

Program received signal SIGTRAP, Trace/breakpoint trap.

Da ich mit Breakpoints gearbeitet habe, gehe ich davon aus, dass ich in eine “Breakpoint-Falle” getappt bin. Was ist eine Haltepunktfalle?

  • Ausführlicheren Titel hinzugefügt. Es wird dem anderen Benutzer helfen

    – Shiplu Mokadim

    21. März 2012 um 17:09 Uhr

  • Dies ist auch die Art von Frage, die Sie auf posten können Elektronik SE.

    – Kortuk

    21. März 2012 um 17:53 Uhr


  • @Kortuk Inwiefern hat dieser GDB Qn mit Elektronik zu tun? :-Ö

    – Pavan Manjunath

    21. März 2012 um 18:17 Uhr

  • Typ info breakpoints und stellen Sie sicher, dass alle Haltepunkte gelöscht sind.

    – Pavan Manjunath

    21. März 2012 um 18:27 Uhr

  • @PavanManjunath, das Embedded hat mich erwischt, und wenn ich ein Programm wie GDB nicht kenne, verbringe ich nicht zu viel Zeit damit, mir Gedanken über das Produkt zu machen. Ich schaue mir nur alles an, was mit Embedded gekennzeichnet ist, und schreibe gelegentlich Kommentare. Wir unterstützen Embedded-Arbeiten. Wir sind wahrscheinlich in erster Linie Entwickler von eingebetteten Systemen, obwohl viele wie ich Mikrocontroller der unteren Preisklasse meinen. Dies ist eine Frage, die auf beide Seiten passt, aber SO wird von viel mehr Leuten durchsucht, also ein Vorteil, hier zu posten. Elektronik ist die Website für Elektrotechnik, früher Elektronikdesign, aber Markenprobleme.

    – Kortuk

    21. März 2012 um 18:27 Uhr

Haltepunktfalle bedeutet nur, dass der Prozessor einen Haltepunkt erreicht hat. Es gibt zwei Möglichkeiten, warum dies geschieht. Höchstwahrscheinlich wird Ihr Initialisierungscode getroffen, weil Ihre CPU zurückgesetzt wird und den Haltepunkt erneut erreicht. Die andere Möglichkeit wäre, dass der Code, in dem Sie den Haltepunkt setzen, tatsächlich an anderen Stellen als der Initialisierung ausgeführt wird. Manchmal kann es bei aggressiver Compiler-Optimierung schwierig sein, genau zu sagen, welchem ​​Code Ihr Haltepunkt zugeordnet ist und welche Ausführungspfade dorthin führen können.

  • Wenn die CPU zurückgesetzt wird, wäre GDB noch am Leben und an die ausführbare Datei des Benutzers angehängt?

    – Pavan Manjunath

    21. März 2012 um 18:19 Uhr


  • @PavanManjunath, ja, es ist möglich, dass die CPU zurückgesetzt und dann den Haltepunkt erreicht, ohne die GDB-Sitzung zu stören.

    – TJD

    21. März 2012 um 19:16 Uhr

  • In einigen Systemen stoppt die Ausführung am Einstiegspunkt, anstatt direkt zu main zu gehen, wenn eine Debug-Sitzung gestartet wird. Wenn Sie dies sehen, kann dies bedeuten, dass Ihr System abgestürzt ist und zum Code-Einstiegspunkt gegangen ist.

    – m4l490n

    27. Oktober 2020 um 16:24 Uhr

Die andere Möglichkeit die mir einfällt ist:

1. Ihr Prozess läuft mehr als ein Faden.

Sagen Sie für zB – 2 x & y.

2.Thread y erreicht den Haltepunkt aber Sie haben gdb an Thread x angehängt.

Dieser Fall ist ein Trace/Breakpoint-Trap.

  • Dies ist ein häufiges Symptom bei der Verwendung von Unit-Test-Frameworks, die die Testfälle verzweigen. Gut zu wissen!

    – Damian Nadales

    19. August 2015 um 9:57 Uhr

Ich habe dieses Problem beim Ausführen des Linux-Projekts in Visual Studio 2015 und beim Remote-Debuggen. Meine Lösung ist project_properties -> Konfigurationseigenschaften -> Debugging -> Debugging-Modus und ändern Sie den Wert von “gdbserver” auf “gdb”

Benutzer-Avatar
Maik Siebrand

Wenn Sie V BAT als Backup-Versorgung verwenden und Ihre Backup-Spannung niedriger als 1,65 V ist, tritt nach dem Anschließen an eine Stromversorgung das gleiche Problem auf.

In diesem Fall müssen Sie alle Stromversorgungen trennen und mit korrekter Spannung wieder anschließen. Dann verschwindet das Problem mit dem Debuggen.

Ich habe das gleiche Problem und in meinem Fall besteht die Lösung darin, die SWD-Frequenz zu verringern. (Ich habe Lötpersonal zwischen MCU und Host, nicht so zuverlässig) Ich habe 4000k auf 100k geändert und das Problem ist weg.

1384510cookie-checkProgrammempfangssignal SIGTRAP, Trace/Breakpoint-Trap

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy