Vous avez expédié, vous obtenez une faute de segmentation rare. Vérification du pointeur ou laisser aller?

9

Vous avez expédié, les assertions sont désactivées, vous recevez un rapport de crash rare indiquant qu'une violation de pointeur nul s'est produite dans votre code. Dans un environnement de développement, le problème aurait été rattrapé par une affirmation.

Tout ce que vous avez est un rapport d'erreur, donc reproduire le problème est presque impossible. Suivre la trace ne donne aucun indice sur la raison pour laquelle l'accident s'est produit en premier lieu.

Options: - Ajouter une vérification du pointeur pour éviter le plantage. Cela empêchera le crash, mais vous ne saurez probablement même pas pourquoi cela s'est produit en premier lieu. - laissez-le voler, j'espère que cela se reproduira avec un scénario de repro

Disons que l'application n'est pas destinée à un missile guidé ou à un système de freinage automatique ...

Lequel choisiriez-vous?

bug pointers

— MM01
source

À moins que cela ne soit réthorique, il pourrait être utile de publier le rapport de plantage avec les fichiers de code correspondants (peut-être sur Pastebin.com) sur le site Stack Overflow si vous voulez que cela soit résolu ...

— Tamara Wijsman

2

@TomWij: Ne le pense pas ... il sera très probablement fermé comme "trop localisé"

— Naveen

@Naveen: Peut-être ... je ne suis pas un visiteur régulier de SO, donc c'était un commentaire d'esprit SU.

— Tamara Wijsman

1

@Naveen: Trop localisé signifie trop régional, c'est une question de géographie et non de spécialisation de la question. Mais cette question serait probablement fermée sur SO par subjectivité.

— Maniero

7

J'ai choisi la deuxième approche. Il est inutile de masquer le crash si le pointeur NULL était inattendu au point où le crash s'est produit. Ce pointeur NULL dans la plupart des cas serait juste l'un des symptômes de quelque chose d'autre qui ne va pas. Si nous le cachons avec un pointeur NULL, il est presque certain que quelque chose d'autre se cassera. Je pense que vous avez une meilleure chance d'attraper le scénario si vous connaissez le point où il se bloque à chaque fois à un endroit aléatoire.

— Naveen
source

1

Je penche moi-même vers cette opinion. La perception des utilisateurs est ce qui m'inquiète. Un crash semble clairement que quelque chose a mal tourné. Cependant, si une fonction obtient un calcul complètement faux, cela sera également remarqué.

— MM01

2

À mon avis, même si l'utilisateur peut être irrité par le crash occasionnel, il sera vraiment contrarié s'il donne un mauvais résultat car il pourrait passer inaperçu.

— Naveen

planter le plus tôt possible, cela vous aide à trouver le problème, et cela aide l'utilisateur à perdre moins de données

— Spudd86

j'utiliserais également valgrind pour découvrir ce que je fais mal (ou au moins j'essaierais, dans tous les cas il pourrait trouver des problèmes que vous devriez résoudre) j'ajouterais des assertions supplémentaires pour essayer d'attraper le pointeur NULL plus tôt et demandez à l'utilisateur d'essayer d'exécuter un build dont les assertions sont activées pendant un certain temps pour voir s'il peut le faire planter plus tôt

— Spudd86

3

À quelle fréquence le crash se produit-il? Cela arrive juste pour un client sur plusieurs dans un cas obscur? Quelles en sont les conséquences (perte de données, plantage du système)? Si cela se produit tous les 1 sur un million de cas et qu'ils n'ont qu'à redémarrer l'application et qu'aucune donnée n'est perdue, alors vous n'avez probablement pas besoin de la réparer - laissez-la comme ça.
Combien coûte (argent et temps) d'ajouter les assertions et de les expédier à tous les clients (si seulement une partie des clients obtient la nouvelle version, le reste pourrait se retrouver dans le problème nul non vérifié)? Quelles sont les chances de trouver le problème? Si vous venez de mettre des contrôles aléatoires dans le code dans l'espoir de détecter l'erreur, c'est une mauvaise pratique ...
Le problème peut-il être reproduit sur la machine du client? Pouvez-vous accéder à cette machine? Cela pourrait être vraiment précieux
Examinez vos rapports de plantage et assurez-vous que les informations fournies sont utiles et peuvent vous aider à diagnostiquer le problème

— Victor Hurdugaci
source

2

_{Dans un environnement de développement, le problème aurait été rattrapé par une affirmation.}

_{Dans un ordre spécifique, il aurait été capturé et corrigé, mais la trace arrière actuelle n'a jamais été détectée.

Vous devriez pouvoir voir ce qui n'a pas fonctionné avec le vidage sur incident, avez-vous vérifié les paramètres, etc ...?}

Les extras qui peuvent être effectués en fonction du temps que vous souhaitez y consacrer:

Archiver le vidage sur incident et y faire référence dans le code avec un commentaire sur la ligne sur laquelle il s'est écrasé,
cela permet à celui qui examine un vidage chrash très similaire de savoir qu'il s'est déjà produit avant ...
[temps passé: court]
Vérifications supplémentaires, journalisation, ... Vous voulez l'empêcher et obtenir plus d'informations la prochaine fois.
[temps passé: moyen]

Une violation de pointeur nulle s'est produite dans votre code.
Vérifiez qu'il est impossible d'appeler l'application de cette manière pour que cette violation se produise.
[temps passé: long]

— Tamara Wijsman
source

1

Ce message n'est pas tant sur l'approche pour résoudre le problème, mais plutôt sur le plan d'action dans une situation hypothétique (c'est-à-dire dans le délai imparti, la source du problème n'a pas pu être déduite).

— MM01

2

Ces jours-ci, j'expédie avec assert () activé. Cela ne coûte pas cher et peut rendre la vie beaucoup plus facile dans des situations hostiles (c'est-à-dire que les environnements de vos clients sont souvent plus hostiles que vos environnements de développement ou d'assurance qualité).

— Mitch Haile
source