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... 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. 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.

  • 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


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]

  • 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).

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.