You've shipped, asserts are turned off, you receive a rare crash report indicating that a null pointer violation occurred in your code. In a development environment, the problem would have been caught by an assert.

All you have is a crash report, so reproducing the issue is near impossible. Following the backtrace doesn't give any clues as to why the crash happened in the first place.

Options: - Add pointer checking to prevent the crash. This will prevent the crash, but you probably won't even find out why it happened in the first place. - let it fly, hope that it happens again with a repro scenario

Let's say the application isn't intended for a guided missle or automatic braking system...

Which would you choose?

  • Unless this is rethorical, it might be handy to post the crash report together with the corresponding code files (perhaps on Pastebin.com) to the Stack Overflow site if you want this to be solved... – Tamara Wijsman Sep 14 '10 at 11:28
  • 2
    @TomWij: Don't think so..it will most probably get closed as "too localized" – Naveen Sep 14 '10 at 11:37
  • @Naveen: Maybe... I'm not a regular SO visitor so this was a SU-mind comment. – Tamara Wijsman Sep 14 '10 at 12:01
  • 1
    @Naveen: Too localized means too regional, it's about geography and not about specialization of issue. But this question probably would be closed on SO by subjectiveness. – Maniero Sep 14 '10 at 13:11

I chose the second approach. There is no point in hiding the crash if the NULL pointer was unexpected at the point where crash has occured. This NULL pointer in most cases would just be one of the symptom of something else is wrong. If we hide it with a NULL pointer check it is almost certain that something else will break. I feel you have a better chance catching the scenario if you know the point where it crashes everytime instead at some random place.

| improve this answer | |
  • 1
    I'm leaning towards this opinion myself. The user perception is what worries me. A crash clearly looks like something has gone wrong. However, if a feature get's a calculation completely wrong, this will also be noticed. – MM01 Sep 14 '10 at 12:34
  • 2
    In my opinion even though user may get irritated by the occasional crash, they will get really upset if it provides wrong result as it might go unnoticed. – Naveen Sep 14 '10 at 12:56
  • crash as early as possible, it helps you find the problem, and it helps the user loose less data – Spudd86 Nov 25 '10 at 19:24
  • also I'd use valgrind to find out what I'm doing wrong (or at least I'd try, in any case it might find some issues you should fix) I'd add additional asserts to try catch the NULL pointer earlier and ask the user to try running a build that has asserts turned on for a while to see if they can get it to crash earlier – Spudd86 Nov 25 '10 at 19:27
  1. How often does the crash occur? It happens just for one in many customers in some obscure case? What are the consequences (data loss, system crash)? If it happens every 1 in a million cases and they just have to restart the application and no data is lost then probably you don't need to fix it - leave it like that.

  2. How expensive (money and time) is to add the asserts and ship it to all customers(if just a part of the customers get the new version then the rest might get into the not checked null problem)? What are the chances of finding the problem? If you just put random checks in the code hoping to catch the error then is a bad practice...

  3. Can the problem be reproduced on the customer's machine? Can you get access to that machine? This might be really valuable

  4. Review your crash reports and make sure the information provided is useful and can help you diagnose the problem

| improve this answer | |

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

In a specific order it would have been caught and fixed, but the current back-trace has never been caught.
You should be able to see what went wrong with the crash dump, have you checked parameters, etc...?

The extras that can be done based on the amount of time you want to put into this:

  • Archive the crash dump and refer to it in the code with a comment at the line it crashed,
    this allows one that examines a very similar chrash dump to know that it has happened before...
    [time spent: short]

  • Additional checks, logging, ... You want to prevent it and get more information next time.
    [time spent: medium]

    Null pointer violation occurred in your code.

  • Check that it's impossible to call the application in such way for this violation to happen.
    [time spent: long]

| improve this answer | |
  • 1
    This post isn't so much about the approach to solving the issue, but rather the course of action in a hypothetical situation (i.e. in the time frame allocated, the source of the issue could not be deduced). – MM01 Sep 14 '10 at 11:58

These days, I ship with assert() turned on. It doesn't cost much and it can make life a lot easier in hostile situations (i.e., your customer's environments are often more hostile than your dev or QA environments).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.