I've come across an error that has me rather stumped. I was testing some exception handling code and found that my program was crashing with an "Access violation reading location 0x0000000000000000." error in the <ostream> header. Figuring it was probably a problem where I accidentally double delete'd something or forgot to release a handle somewhere I started commenting out code to try and narrow down what is causing it. This is where things got weird. I've been able to reproduce it with a very minimal set of code (still larger than I'd like to post here though...). The thing is if I comment out a few functions that are never run, it will compile and run fine, no errors. If I reintroduce the code (ie. uncomment it), these same functions that are never called and never run, it will produce the error.

I'm currently using VS2012 express edition. I've tried it with both the default toolset and the November CTP toolset (with identical results). I've tried it with both 32 and 64-bit and under both debug and release and all give the same results. I've played with every compiler and linker setting I can think of to no avail.

Anyone have any idea of what I should try next?

I'd have to suggest posting the code. I have no idea what to make of a null pointer access just from hearing its name.

Also, see if there's some sort of memory debugger that you can use. One of the first programs I turn to for things like this is Valgrind, which would give you a heads-up once various memory errors occur.

Also, see if there's some sort of memory debugger that you can use. One of the first programs I turn to for things like this is Valgrind, which would give you a heads-up once various memory errors occur.

"VS2012 express edition"

Valgrind does not run on Windows.

The problem with posting the code is that when I try to bring code from other files into the main file (so I can post it all in one spot), identical copy-pasted code will cause it to go from not working, to working. For example, here's the main part I was able to trim it down to (this does not work):

struct TestException : public Exception {};		// class Exception : virtual public boost::exception, virtual public std::exception

std::string GetLineNumber (const boost::exception& e) {
	std::stringstream ss;
	//ss << 15;
	return ss.str();
	}

// ----- WinMain -----
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {

	bool show_exception = false;
	std::string error_msg = "No error has occured.";

	try {
		throw_detailed(TestException());
		}
	catch (const Exception& e) {
		show_exception = true;
		//error_msg = e.GetWindowsErrorMessage();
		error_msg = e.GetLineNumber();
		//error_msg = GetLineNumber(e);
		}
	
	return 0;
	}

Now if I uncomment the line "ss << 15;" it will compile and run fine. Notice how the function is never called. I was trying to include throw_detailed which consists of:

// ----- special includes -----
#include <boost\exception\detail\attribute_noreturn.hpp>


// ----- ExceptionCore -----
namespace ExceptionCore {

	typedef boost::error_info<struct tagTypeInfo,std::string> TypeMsgInfo;

	template <typename T> BOOST_ATTRIBUTE_NORETURN void ThrowException (T& e, const char* func, const char* file, int line) {
		e << TypeMsgInfo(typeid(T).name());
		e << ::boost::throw_function(func);
		e << ::boost::throw_file(file);
		e << ::boost::throw_line(line);
		throw e;
		}
	}


// ----- throw macro ----
//#define throw_detailed(x) BOOST_THROW_EXCEPTION(x)
#define throw_detailed(x) ::ExceptionCore::ThrowException(x,BOOST_CURRENT_FUNCTION,__FILE__,__LINE__)

into main. But as soon as I copy and paste it in main, it works. Basically anytime I change any of the code, related or not, it seems to change between working/not working, and I can find no pattern. I've traced every intermediate value and with the VS2012 debugger they all are correct values at each step along the way.

Also, see if there's some sort of memory debugger that you can use. One of the first programs I turn to for things like this is Valgrind, which would give you a heads-up once various memory errors occur.

"VS2012 express edition"

Valgrind does not run on Windows.

I know. I never said it did. Actually, more accurately, it does: http://sourceforge.net/projects/valgrind4win/, but it doesn't work with VS.

Now if I uncomment the line "ss << 15;" it will compile and run fine. Notice how the function is never called.

One thing I can think of is that with the line uncommented, that templated member function becomes instantiated. Does it make a difference if you copy the body of this function to some other point in the code?

If I copy this function below main it makes no difference. Remove the function completely and it still causes an error. Are you suggesting that the line "ss << 15" forces instantiation of operator<< where-as without it the member function is not? After playing around with commenting and uncommenting the code I had a feeling the error was something to do with operator<<, but I wasn't really sure what about it. That seems like an interesting line of attack. Now isn't the compiler supposed to instantiate the functions automatically when it encounters them? So would this be a compiler issue?

If I copy this function below main it makes no difference.

I mean take the stringstream declaration, and use, and put it in a different function entirely, just for now.

Are you suggesting that the line "ss << 15" forces instantiation of operator<< where-as without it the member function is not?

Now isn't the compiler supposed to instantiate the functions automatically when it encounters them? So would this be a compiler issue?

When it encounters them, yes, but with it commented out, it is never used; the compiler never processes what's in comments. I'm not sure if it is implementation defined, but my compiler does not instantiate a member function if it is never called, in order to cut down on executable size. This leads to frustrating bugs that I overlook, because I never used the function, thus the compiler never instantiates it and points out an obvious bug.

So, call it a long shot, but perhaps something relies on this operator <<() function being instantiated, and when it isn't instantiated in any of the objects linked together, the program crashes. This reminds me of a compiler bug discovered not too long ago, where virtual functions were being declared as inline, and thus the compiler never instantiated the function as a normal function, leading to a crash when the program attempted to access the function through the vtable.

Defining a virtual function as an inline function is legal, and has uses, but the compiler is supposed to make a normal function instantiation as well, so that it can be called via function pointer. The bug was that the normal out-of-line instantiation wasn't made, thus the function pointer pointed to garbage.