Debuggen von c++ : ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory

Ich bin mit gdb Debuggen C++ Programm. In der Zeile

assert(prevId ==  GetTagIdFromState(maxState));

die parameter prevId Wert ist 0;
die Methode GetTagIdFromState(maxState) returns 50;

beim Debuggen, bekomme ich die folgenden Fehler.

Assertion `prevId == GetTagIdFromState(maxState)' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff6ecbba5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64    ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
      in ../nptl/sysdeps/unix/sysv/linux/raise.c

Wenn jemand stolperte über dieses, ich hatte den gleichen Fehler. Was gelöscht es meine war, da war eine Sperre, die gesperrt wurde, aber nie veröffentlicht. Ich bin mir nicht sicher, warum es ist nicht einfach deadlock. Weiß nicht, ob das wird helfen, aber dachte, würde ich pass auf meine gotcha.

InformationsquelleAutor wangzhiju | 2012-10-31

c++gdb

9

Ihre Anwendung funktioniert wie vorgesehen. Die assertion fehlschlägt (da die Werte, die Sie passieren, um es nicht gleich, die assert makro erhält 0), und damit dein Programm wird abgebrochen. Das ist, wie behauptet arbeiten:

Wenn NDEBUG nicht definiert ist, dann assert prüft, ob das argument (die
muss skalaren Typ) vergleicht gleich null. Wenn Sie es tut, behaupten
Ausgänge Implementierung-spezifische Diagnose-Informationen auf die standard -
Fehler-Ausgang und ruft std::abort.

Hervorhebung von mir.

Überprüfen diese Referenz geltend machen für weitere Informationen.
- Danke erstmal. Ich bin neu in C++. Ich wusste, dass die Behauptung nicht, jedoch können Sie mir einen Rat geben, warum der Fehler "../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory." araises. Es scheint, dass das Programm kann nicht die Datei gefunden.
- Es ist nichts zu befürchten. Das assert-makro aufrufen (wahrscheinlich indirekt) eine Funktion namens zu erhöhen. Dies geschieht innerhalb einer Bibliothek, die Sie verknüpfen mit Ihrem code. Wenn die Bibliothek kompiliert wurde (auf einer anderen Maschine) gab es eine Datei namens " ../nptl/sysdeps/unix/sysv/linux/raise.c', aber jetzt, wenn es auf Ihrem Computer die Datei nicht mehr vorhanden ist. Wenn Sie wollen, um diesen Fehler Weg gehen, dann werden Sie wahrscheinlich haben, um den Quellcode herunterzuladen für diese Bibliothek.
- naja, ausgehend von dem Pfad, wie es aussieht ist die lib die du verwenden kompiliert wurde es auf der Entwickler-Maschine mit Verwendung einer Datei ../nptl/sysdeps/unix/sysv/linux/raise.c. Da gibt es keine solche Datei auf Ihrem Computer, müssen Sie den Fehler. Es sollte nicht dazu führen, dass jeder Probleme aber so könnten Sie auch ignorieren.
InformationsquelleAutor SingerOfTheFall
0

Sollte dies bringen Sie auf den neuesten Stand über die Verwendung von assert-Funktion
```
void assert (int expression);
```
Bewerten Behauptung
Wenn das argument Ausdruck dieses makro mit funktionalen form vergleicht gleich null ist (D. H., der Ausdruck ist false), wird eine Nachricht geschrieben, auf die standard-Fehler-Gerät und der Abbruch wird genannt, beendet die Programmausführung.

Den Besonderheiten der angezeigte Meldung hängt von der spezifischen Implementierung im compiler, aber er muss Folgendes enthalten: den Ausdruck dessen assertion fehlgeschlagen ist, wird der name der Quelldatei und die Zeilennummer, wo es passiert ist. Eine übliche Ausdruck format:

Assertion failed: Ausdruck, file filename, line Zeilennummer
Dieses makro ist deaktiviert, wenn im moment des darunter geltend zu machen.h ein makro mit dem Namen NDEBUG bereits definiert wurde. Dies ermöglicht ein Programmierer gehören viele assert-Aufrufe im Quellcode beim Debuggen Sie das Programm und deaktivieren Sie dann alle von Ihnen für die Produktion-version einfach mit einer Zeile wie:
```
#define NDEBUG at the beginning of its code, before the inclusion of assert.h.
```
Daher, dieses makro dient der Erfassung Fehler in der Programmierung, nicht auf die Benutzer ausgeführt oder Fehler, da Sie in der Regel deaktiviert, nachdem ein Programm beendet seine debugging-phase.
von: C++ Ref

InformationsquelleAutor Alireza Soori
0

Ich habe gerade festgestellt das Fehler beim Debuggen eines Programms auf einem Raspberry Pi. Das Programm geschieht die Verwendung der GPIO in einer Weise, die erfordert, dass das Programm als Benutzer root ausgeführt werden. Zum Beispiel, ich starte das Programm, das ich schrieb wie diese:
```
sudo ./foo
```
Ich vergaß dies jedoch, beim starten des debugger und versuchte
```
gdb foo
```
Und ich bekam die Fehlermeldung, die Sie zu haben scheinen, begegnet:
```
Program received signal SIGABRT, Aborted.
0x76cd0f70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
```
Bei mir lief es mit Hilfe von sudo, es hat gut funktioniert.
```
sudo gdb foo
```
Hoffe, es ist hilfreich, jemanden im gleichen Boot.
- Auch nach der Verwendung von sudo, der Fehler bleibt
- mein Programm muss als root laufen, und trifft eine Behauptung, wenn es nicht läuft als solche. Die Behauptung, die Sie schlagen, ist wahrscheinlich verursacht durch einige andere Fehler aufgetreten sind. Der Fehler in dieser Frage heißt, eine Behauptung getroffen wurde. In meinem Fall, die Behauptung war zufrieden, durch ausführen des Programms als root.
InformationsquelleAutor Marvo

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.