Question

I am getting a NullReferenceException when running my multi-threaded application, but only when I run in Release mode outside of the debugger. The stack trace gets logged, and it always points to the same function call. I put several logging statements in the function to try to determine how far it would get, and every statement gets logged, including one on the last line of the function. What is interesting is that when the NullReferenceException occurs, the statement after the function call does not get logged:

    // ...
    logger.Log( "one" );  // logged
    Update( false );
    logger.Log( "eleven" );  // not logged when exception occurs
}

private void Update( bool condition )
{
    logger.Log( "one" );  // logged
    // ...  
    logger.Log( "ten" );  // logged, even when exception occurs
}

The exception does not occur every time the function is called. Is it possible that the stack is being corrupted either before or during execution of the function such that the return address is lost, resulting in the null reference? I didn’t think that sort of thing was possible under .NET, but I guess stranger things have happened.

I tried replacing the call to the function with the contents of the function, so everything happens inline, and the exception then occurs on a line that looks like this:

foreach ( ClassItem item in classItemCollection )

I have verified through logging that the “classItemCollection” is not null, and I also tried changing the foreach to a for in case the IEnumerator was doing something funny, but the exception occurs on the same line.

Any ideas on how to investigate this further?

Update: Several responders have suggested possible solutions having to do with making sure the logger isn’t null. To be clear, the logging statements were added for debugging purposes after the exception started happening.

Answer 1

I found my null reference. Like Fredrik and micahtan suggested, I didn’t provide enough information for the community to find a solution, so I figured I should post what I found just to put this to rest.

This is a representation of what was happening:

ISomething something = null;

//...

// the Add method returns a strong reference to an ISomething
// that it creates.  m_object holds a weak reference, so when
// "this" no longer has a strong reference, the ISomething can
// be garbage collected.
something = m_object.Add( index );

// the Update method looks at the ISomethings held by m_object.
// it obtains strong references to any that have been added,
// and puts them in m_collection;
Update( false );

// m_collection should hold the strong reference created by 
// the Update method.
// the null reference exception occurred here
something = m_collection[ index ];

return something;

The problem turned out to be my use of the “something” variable as a temporary strong reference until the Update method obtained a permanent one. The compiler, in Release mode, optimizes away the “something = m_object.Add();” assignment, since “something” isn’t used until it is assigned again. This allowed the ISomething to be garbage collected, so it no longer existed in m_collection when I tried to access it.

All I had to do was ensure that I held a strong reference until after the call to Update.

I am doubtful that this will be of any use to anyone, but in case anyone was curious, I didn’t want to leave this question unanswered.