Hai spedito, ottieni un raro difetto di seg. Puntatore che controlla o lascia andare?

8

Hai spedito, gli assert sono disattivati, ricevi un rapporto di raro che indica che si è verificata una violazione del puntatore nullo nel codice. In un ambiente di sviluppo, il problema sarebbe stato catturato da un assert.

Tutto ciò che hai è un rapporto di crash, quindi riprodurre il problema è quasi impossibile. Seguire il backtrace non fornisce alcun indizio sul motivo per cui l'arresto si è verificato in primo luogo.

Opzioni: - Aggiungi controllo puntatore per prevenire l'arresto anomalo. Ciò impedirà il crash, ma probabilmente non scoprirai nemmeno perché è successo in primo luogo. - lascia volare, spero che accada di nuovo con uno scenario di repro

Diciamo che l'applicazione non è intesa per un missile guidato o un sistema di frenatura automatica ...

Quale sceglieresti?

    
posta MM01 14.09.2010 - 11:32
fonte

4 risposte

7

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

    
risposta data 14.09.2010 - 13:29
fonte
3
  1. Con quale frequenza si verifica l'arresto anomalo? Succede solo per uno in molti clienti in un caso oscuro? Quali sono le conseguenze (perdita di dati, crash di sistema)? Se succede ogni 1 su un milione di casi e devono solo riavviare l'applicazione e nessun dato andrà perso, probabilmente non hai bisogno di aggiustarlo - lascialo così.

  2. Quanto è costoso (tempo e denaro) aggiungere gli asserzioni e spedirli a tutti i clienti (se solo una parte dei clienti ottiene la nuova versione, il resto potrebbe entrare nel problema null non controllato)? Quali sono le possibilità di trovare il problema? Se metti solo controlli casuali nel codice sperando di catturare l'errore, allora è una cattiva pratica ...

  3. Il problema può essere riprodotto sul computer del cliente? Puoi avere accesso a quella macchina? Questo potrebbe essere davvero prezioso

  4. Verifica i rapporti sugli arresti anomali e assicurati che le informazioni fornite siano utili e possano aiutarti a diagnosticare il problema

risposta data 14.09.2010 - 13:28
fonte
2

In a development environment, the problem would have been caught by an assert.

In un ordine specifico sarebbe stato catturato e riparato, ma il tracciato attuale non è mai stato catturato.
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 inserire in questo:

  • Archiviare il dump di arresto anomalo del sistema e fare riferimento ad esso nel codice con un commento sulla linea in cui si è verificato il crash,
    questo permette a uno che esamina un dump di crash molto simile per sapere che è successo prima ...
    [tempo trascorso: breve]

  • Controlli aggiuntivi, registrazione, ... Vuoi impedirlo e ottenere maggiori informazioni la prossima volta.
    [tempo trascorso: medio]

    Null pointer violation occurred in your code.

  • Controlla che sia impossibile chiamare l'applicazione in questo modo affinché questa violazione si verifichi.
    [tempo trascorso: lungo]

risposta data 14.09.2010 - 13:27
fonte
2

In questi giorni, spedisco con assert () acceso. 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 controllo qualità).

    
risposta data 26.09.2010 - 06:07
fonte

Leggi altre domande sui tag