奇怪的空引用异常

Question

So I have this code that takes care of command acknowledgment from remote computers, sometimes (like once in 14 days or something) the following line throws a null reference exception:

computer.ProcessCommandAcknowledgment( commandType );

What really bugs me is that I check for a null reference before it, so I have no idea whats going on. Here's the full method for what its worth:

    public static void __CommandAck( PacketReader reader, SocketContext context )
    {
        string commandAck = reader.ReadString();

        Type commandType = Type.GetType( commandAck );

        Computer computer = context.Client as Computer;

        if (computer == null)
        {
            Console.WriteLine("Client already disposed. Couldn't complete operation");
        }
        else
        {
            computer.ProcessCommandAcknowledgment( commandType );
        }
    }

Any clues?

Edit: ProcessCommandAcknowledgment:

    public void ProcessCommandAcknowledgment( Type ackType )
    {
        if( m_CurrentCommand.GetType() == ackType )
        {
            m_CurrentCommand.Finish();
        }
    }

Answer 1

Based on the information you gave, it certainly appears impossible for a null ref to occur at that location. So the next question is "How do you know that the particular line is creating the NullReferenceException?" Are you using the debugger or stack trace information? Are you checking a retail or debug version of the code?

If it's the debugger, various setting combinations which can essentially cause the debugger to appear to report the NullRef in a different place. The main on that would do that is the Just My Code setting.

In my experience, I've found the most reliable way to determine the line an exception actually occurs on is to ...

1. Turn off JMC
2. Compile with Debug
3. Debugger -> Settings -> Break on Throw CLR exceptions.
4. Check the StackTrace property in the debugger window

Answer 2

Is it possible that ReadString() is returning null? This would cause GetType to fail. Perhaps you've received an empty packet? Alternatively, the string may not match a type and thus commandType would be null when used later.

EDIT : Have you checked that m_CurrentCommand is not null when you invoke ProcessCommandAcknowledgment ?

Answer 3

I would bet money that there's a problem with your TCP framing code (if you have any!)

"PacketReader" perhaps suggests that you don't. Because, technically, it would be called "FrameReader" or something similar if you did.

If the two PC's involved are on a local LAN or something then it would probably explain the 14 days interval. If you tried this over the Internet I bet your error frequency would be much more common especially if the WAN bandwidth was contended.

Answer 4

If you have optimizations turned on, it's likely pointing you to a very wrong place where it actually happens.

Something similar happened to me a few years back.

Answer 5

Or else a possible thread race somewhere where context gets set to null by another thread. That would also explain the uncommonness of the error.

Answer 6

Okay, ther are really only a few possibilities.

1. Somehow your computer reference is being tromped by the time you call that routine.

2. Something under the call is throwing the null pointer dereference error but it's being detected at that line.

Looking at it, I'm very suspicious the stack is getting corrupted, causing your computer automatic to get mangled. Check the subroutine/method/function calls around the one you have trouble with; in particular, check that what you're making into a "Computer" item really is the type you expect.

Answer 7

What are the other thread(s) doing?

Edit: You mention that the server is single threaded, but another comment suggests that this portion is single threaded. If that's the case, you could still have concurrency issues.

Bottom line here, I think, is that you either have a multi-thread issue or a CLR bug. You can guess which I think is more likely.

Answer 8

computer.ProcessCommandAcknowledgment( commandType );

Do you have debugging symbols to be able to step into this?

The null ref exception could be thrown by ProcessCommandAcknowledgement, and bubble up.