2012-10-31 11 views
8

Sto utilizzando gdb per eseguire il debug di un programma C++. Nella lineadebugging C++: ../nptl/sysdeps/unix/sysv/linux/raise.c: Nessun file o directory

assert(prevId == GetTagIdFromState(maxState)); 
  • il parametro prevId valore è 0;
  • il metodo GetTagIdFromState(maxState)return s 50;

durante il debug di questo errore, ricevo i seguenti errori.

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 
+0

Se qualcuno si è imbattuto in questo, ho avuto lo stesso errore. Ciò che ha chiarito il mio era che c'era un lucchetto chiuso a chiave, ma mai rilasciato. Non sono sicuro del motivo per cui non si è appena bloccato. Non so se questo ti sarà d'aiuto, ma ho pensato che avrei passato il mio trucchetto. – Homer6

risposta

7

L'applicazione funziona come previsto. L'asserzione fallisce (poiché i valori che gli si passano non sono uguali, la macro assert riceve 0) e quindi il programma viene interrotto. Ecco come afferma lavoro:

Se NDEBUG non è definito, quindi affermano controlla se il suo argomento (che must tipo scalare) confronta uguale a zero. In tal caso, asserire restituisce informazioni diagnostiche specifiche dell'implementazione sull'output di errore standard e chiama std :: abort.

enfasi mia.

Verificare this assert reference per ulteriori informazioni.

+5

Grazie per la prima volta. Sono nuovo di C++. Sapevo che l'asserzione fallisce, ma puoi darmi qualche consiglio sul perché l'errore "../nptl/sysdeps/unix/sysv/linux/raise.c: Niente file o directory." araises. Sembra che il programma non possa trovare il file. – wangzhiju

+4

Non c'è niente di cui preoccuparsi. La macro assert sta chiamando (probabilmente indirettamente) una funzione chiamata raise. Questo sta accadendo all'interno di una libreria che stai collegando con il tuo codice. Quando questa libreria è stata compilata (su qualche altra macchina) c'era un file chiamato '../nptl/sysdeps/unix/sysv/linux/raise.c', ma ora quando è in esecuzione sulla tua macchina quel file non esiste più. Se vuoi eliminare questo errore, probabilmente devi scaricare il codice sorgente per questa libreria. – john

+0

@wangzhiju, beh, a giudicare dal percorso, sembra che la lib che stai usando sia stata compilata sulla macchina dello sviluppatore con l'uso di un file '../ nptl/sysdeps/unix/sysv/linux/raise.c'. Poiché non esiste un tale file sul tuo computer, hai l'errore. Non dovrebbe comportare alcun problema, quindi potresti anche ignorarlo. – SingerOfTheFall

0

Questo dovrebbe portare fino a velocità sull'utilizzo di affermare la funzione

void assert (int expression); 

Valutare affermazione Se l'espressione argomento di questa macro con forma funzionale confronta uguale a zero (vale a dire, l'espressione è falsa), un messaggio viene scritto sul dispositivo di errore standard e viene chiamato abort, terminando l'esecuzione del programma.

Le specifiche del messaggio visualizzato dipendono dall'implementazione specifica nel compilatore, ma devono includere: l'espressione la cui asserzione non è riuscita, il nome del file di origine e il numero di riga in cui si è verificato. Un normale formato di espressione è:

Asserzione non riuscita: espressione, nome file file, numero riga Questa macro è disabilitata se al momento di includere assert.h è già stata definita una macro con nome NDEBUG. Questo permette un codificatore per includere molte chiamate asserzione in un codice sorgente durante il debugging del programma e quindi disattivare tutti per la versione di produzione semplicemente includendo una linea come:

#define NDEBUG at the beginning of its code, before the inclusion of assert.h. 

Pertanto, questa macro è progettato per catturare errori di programmazione, non utenti o errori di esecuzione, poiché generalmente è disabilitato dopo che un programma ha terminato la sua fase di debug. da: C++ Ref

0

Ho appena rilevato questo errore durante il tentativo di eseguire il debug di un programma su un Raspberry Pi. Il programma capita di utilizzare il GPIO in un modo che richiede che il programma venga eseguito come root.Per esempio, ho eseguito il programma che ho scritto in questo modo:

sudo ./foo 

ho dimenticato questo, tuttavia, quando si avvia il debugger, e ha cercato

gdb foo 

E ho avuto l'errore ti sembra di aver incontrato :

Program received signal SIGABRT, Aborted. 
0x76cd0f70 in __GI_raise ([email protected]=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. 

Quando l'ho eseguito utilizzando sudo, ha funzionato correttamente.

sudo gdb foo 

Spero che sia utile a qualcuno nella stessa barca.