Metodi di "Code Softening" (di fronte a "Hardening") per C & C ++ [chiuso]

Question

Metodi di "Code Softening" (di fronte a "Hardening") per C & C ++ [chiuso]

#1 da (7 voti)
#2 da (1 voti)

3

Alcuni sviluppatori lavorano sul rafforzamento del codice.

(protezione dagli errori, è possibile creare con una protezione dello stack, ad esempio) .

Tuttavia, se stai tentando di ripetere uno strano rapporto di qualcun altro o di trovare possibili problemi con il codice, potrebbe essere utile il contrario.

Esistono metodi ben noti per aumentare la possibilità che un errore nel codice porti a un arresto anomalo?

Gli esempi potrebbero includere ...

Comprime le strutture in modo che l'accesso fuori campo accidentale non acceda ai byte di riempimento.
Inizializza stack & memoria heap a bit casuali.
Riorganizza l'eseguibile nel layout di memoria per esporre gli errori.
(Per qualsiasi motivo o 'buona fortuna', alcuni bug avranno un impatto solo su configurazioni specifiche) .
Modifica la pianificazione dei thread per esporre bug di threading.

Quindi la domanda è:

Quali sono i metodi esistenti per costruire software, che aiutano a esporre errori nelle applicazioni C / C ++?

Nota, sono a conoscenza di valgrind, address-sanitizer & razionale-purificare.

debugging errors c++ c

posta ParityLentil 10.09.2015 - 15:09

fonte

2 risposte

Leggi altre domande sui tag debugging errors c++ c

Nomi di dominio vs percorso URL per servizi Web Cercando di capire su cosa significa in realtà "user.dir"?

score 7 · Answer 1

In realtà direi che quello che vuoi è ancora più duro. Ti aiuterà a scoprire il bug - se è lì, si manifesterà ad alta voce e più vicino alla causa reale, piuttosto che silenziosamente da qualche parte più tardi.

Se si sta tentando di riprodurre uno strano bug report, suggerirei di non alterare affatto il codice. Ovviamente è meglio se puoi ottenere lo stesso codice, la stessa configurazione di build ed eseguire nello stesso ambiente del reporter. Ma se non puoi o se il bug non si verifica ancora:

valgrind è fantastico, come sai, ha molti attributi con cui puoi giocare
- questo copre la memoria di inizializzazione con bit casuali, valgrind sa che i dati sono unitializzati e qualsiasi accesso in lettura sarà segnalato
compilare ed eseguire il programma su diverse architetture è un modo semplice per far apparire alcuni bug
su linux, compila con -fPIE e assicurati che ASLR sia su
hanno test automatici, i test di unità sono ottimi, ma solo un test fuzzy che pomperà molti dati casuali (validi) nel programma può aiutare

score 1 · Answer 2

Non so se questo è esattamente ciò che è richiesto, ma una volta ho ricevuto un sistema con poche migliaia di righe di codice scritte piuttosto male. Tra le altre cattive pratiche, era pieno di try{ ; } catch(...); , quindi quando si verificava un'eccezione il sistema continuava a funzionare, a volte in modo irregolare. Quello che ho deciso è stato rimuovere completamente la "protezione" esponendo il sistema a un crash, spesso in produzione, in modo da ottenere il dumping. Questa mossa ha aiutato molto.