Hai spedito, ricevi un raro errore di seg. Controllo puntatore o lasciarlo andare?

9

Hai spedito, le asserzioni sono disattivate, ricevi un raro rapporto di arresto che indica che si è verificata una violazione del puntatore null nel tuo codice. In un ambiente di sviluppo, il problema sarebbe stato colto da un'affermazione.

Tutto quello che hai è un rapporto sugli arresti anomali, quindi riprodurre il problema è quasi impossibile. Seguire il backtrace non fornisce alcun indizio sul perché l'incidente sia avvenuto in primo luogo.

Opzioni: - Aggiungi controllo puntatore per evitare l'arresto anomalo. Questo eviterà l'incidente, ma probabilmente non scoprirai nemmeno perché è successo in primo luogo. - lascialo volare, spero che accada di nuovo con uno scenario di riproduzione

Supponiamo che l'applicazione non sia pensata per un missile guidato o un sistema di frenatura automatico ...

Quale sceglieresti?

bug pointers

— MM01
fonte

A meno che non sia retorico, potrebbe essere utile pubblicare il rapporto sugli arresti anomali insieme ai file di codice corrispondenti (forse su Pastebin.com) sul sito Stack Overflow se si desidera che questo venga risolto ...

— Tamara Wijsman

2

@TomWij: Non credo .. molto probabilmente verrà chiuso come "troppo localizzato"

— Naveen,

@Naveen: Forse ... Non sono un normale visitatore SO quindi questo è stato un commento SU-mind.

— Tamara Wijsman,

1

@Naveen: Troppo localizzato significa troppo regionale, riguarda la geografia e non la specializzazione del problema. Ma questa domanda probabilmente verrebbe chiusa su SO dalla soggettività.

— Maniero,

7

Ho scelto il secondo approccio. Non ha senso nascondere l'incidente se il puntatore NULL era inatteso nel punto in cui si è verificato l'incidente. Questo puntatore NULL nella maggior parte dei casi sarebbe solo uno dei sintomi di qualcos'altro che non va. Se lo nascondiamo con un puntatore NULL, è quasi certo che qualcos'altro si romperà. Sento che hai maggiori possibilità di cogliere lo scenario se conosci il punto in cui si blocca ogni volta invece che in un posto casuale.

— Naveen
fonte

1

Mi sto inclinando verso questa opinione. La percezione dell'utente è ciò che mi preoccupa. Un incidente sembra chiaramente che qualcosa sia andato storto. Tuttavia, se una funzione ottiene un calcolo completamente errato, anche questo verrà notato.

— MM01

2

A mio avviso, anche se l'utente può essere irritato dall'incidente occasionale, si arrabbiano molto se fornisce risultati errati in quanto potrebbe passare inosservato.

— Naveen,

crash il più presto possibile, ti aiuta a trovare il problema e aiuta l'utente a perdere meno dati

— Spudd86

inoltre userei valgrind per scoprire cosa sto facendo di sbagliato (o almeno proverei, in ogni caso potrebbe trovare alcuni problemi che dovresti risolvere) aggiungerei ulteriori asserzioni per provare a catturare il puntatore NULL prima e chiedi all'utente di provare a eseguire una build con asserzioni attivate per un po 'per vedere se riescono a farlo arrestare in precedenza in precedenza

— Spudd86

3

Con quale frequenza si verifica l'incidente? Succede solo per uno su molti clienti in qualche caso oscuro? Quali sono le conseguenze (perdita di dati, crash del sistema)? Se succede ogni 1 su un milione di casi e devono solo riavviare l'applicazione e non vengono persi dati, probabilmente non è necessario ripararli - lasciarlo così.
Quanto è costoso (denaro e tempo) aggiungere le affermazioni e spedirle a tutti i clienti (se solo una parte dei clienti ottiene la nuova versione, il resto potrebbe entrare nel problema nullo non verificato)? Quali sono le possibilità di trovare il problema? Se hai appena inserito controlli casuali nel codice sperando di rilevare l'errore, allora è una cattiva pratica ...
Il problema può essere riprodotto sulla macchina del cliente? Puoi avere accesso a quella macchina? Questo potrebbe essere davvero prezioso
Controlla i rapporti sugli arresti anomali e assicurati che le informazioni fornite siano utili e possano aiutarti a diagnosticare il problema

— Victor Hurdugaci
fonte

2

_{In un ambiente di sviluppo, il problema sarebbe stato colto da un'affermazione.}

_{In un ordine specifico sarebbe stato catturato e corretto, ma l'attuale back-trace non è mai stata rilevata.

Dovresti essere in grado di vedere cosa è andato storto con il crash dump, hai controllato i parametri, ecc ...?}

Gli extra che possono essere fatti in base alla quantità di tempo che vuoi mettere in questo:

Archivia il dump di arresto anomalo e fai riferimento ad esso nel codice con un commento sulla riga in cui si è bloccato,
ciò consente a chi esamina un dump di crash molto simile di sapere che è successo prima ...
[tempo trascorso: breve]
Controlli aggiuntivi, registrazione, ... Vuoi impedirlo e ottenere maggiori informazioni la prossima volta.
[tempo trascorso: medio]

Violazione del puntatore null nel codice.
Verifica che sia impossibile chiamare l'applicazione in modo tale che si verifichi questa violazione.
[tempo trascorso: lungo]

— Tamara Wijsman
fonte

1

Questo post non riguarda molto l'approccio alla risoluzione del problema, ma piuttosto il corso dell'azione in una situazione ipotetica (cioè nel periodo di tempo assegnato, la fonte del problema non può essere dedotta).

— MM01

2

In questi giorni, spedisco con assert () attivato. Non costa molto e può rendere la vita molto più facile in situazioni ostili (ad esempio, gli ambienti dei tuoi clienti sono spesso più ostili dei tuoi ambienti di sviluppo o di controllo qualità).

— Mitch Haile
fonte