Skip to main content
GameDev.net gamedev.net
🔒 Locked

Strange Crash On Inclusion of Function

Started by Mercury Sep 28, 2005 at 1:04 PM 7 replies 1.2k views
Original Post
Mercury
Mercury
If I include the following code in my EXE (ie. if I merely compile it in, it's not being used anywhere in the code), my program crashes:
typedef struct
{
	// The name is the tooltip, the path is just that
	string					name, path;
	vector<toolbarIcon_t>	icons;

} toolbar_t;

vector<toolbar_t> getToolbars()
{
	HKEY rootKey;
	vector<toolbar_t> toolbars;

	if (RegOpenKey(HKEY_CURRENT_USER, "Software\\Toolbar", &rootKey) != ERROR_SUCCESS)
	{
		setupRegistry();
		return getToolbars();
	}

	RegCloseKey(rootKey);
	return toolbars;
}

If I comment out that block of code right there, all is well and there is no problem. I get an access violation when that's included inside the XSTRING header that's part of VC++ in this function:
_Myt& assign(const _Myt& _X, size_type _P, size_type _M)
	{if (_X.size() < _P)
		_Xran();
	size_type _N = _X.size() - _P;
	if (_M < _N)
		_N = _M;
	if (this == &_X)
		erase((size_type)(_P + _N)), erase(0, _P);
	else if (0 < _N && _N == _X.size()
		&& _Refcnt(_X.c_str()) < _FROZEN - 1
		&& allocator == _X.allocator)
		{_Tidy(true);
		_Ptr = (_E *)_X.c_str();
		_Len = _X.size();
		_Res = _X.capacity();
		++_Refcnt(_Ptr); }
	else if (_Grow(_N, true))
		{_Tr::copy(_Ptr, &_X.c_str()[_P], _N);
		_Eos(_N); }

I'm using Visual C++ 6 with the latest service pack and I have the current platform SDK installed. I have no clue what's causing this.
Sneftel
Sneftel
So walk up the stack trace in the debugger and find out how that code is being called.
Evil Steve
Evil Steve
Have you tried doing a Rebuild All? MSVC6 does some very strange things sometimes.
Mercury
Mercury
Quote:
Original post by Sneftel
So walk up the stack trace in the debugger and find out how that code is being called.

That's the thing, it's not being called at all (I placed a breakpoint in the function), yet when I include it in the project everything goes to hell.

@Evil Steve: First thing I tried. [sad]
ToohrVyk
ToohrVyk
You still didn't answer Sneftel's suggestion about looking at the back trace.
Sneftel
Sneftel
Quote:
Original post by Mercury
Quote:
Original post by Sneftel
So walk up the stack trace in the debugger and find out how that code is being called.

That's the thing, it's not being called at all (I placed a breakpoint in the function), yet when I include it in the project everything goes to hell.

When your program crashes, walk up the stack trace.
Mercury
Mercury
Quote:
Original post by Sneftel
Quote:
Original post by Mercury
Quote:
Original post by Sneftel
So walk up the stack trace in the debugger and find out how that code is being called.

That's the thing, it's not being called at all (I placed a breakpoint in the function), yet when I include it in the project everything goes to hell.

When your program crashes, walk up the stack trace.

I tried walking up the stack and I found nothing to do with toolbar_t, it's crashing after calling some STL functions from the copy constructor of toolbarIcon_t, which is used in the code before toolbar_t ever is. I can't find any reference to toolbar_t anywhere.
Mercury
Mercury
Could this be a problem with my compiler? I vaguelly recollect having a problem similar to this happening a month ago and it was "fixed" by putting the function into a different source file.

edit: I put the function into a different file in the project and it compiles and all is well. I'm thinking more and more this is a problem with the compiler, but I've never had the problem before.
Enigma
Enigma
It could be your compiler, but it's very unlikely. It's much more probable that you have a more subtle bug in your code and moving the function to a different file is causing sufficient change in your programs layout in memory to mask the problem.

To see how this can occur, consider the following program:
void function1(){}void function2(int * i){	*i = 7;}void foo(){	function1();}void function3(){	int i;	int * j = &i	*(j + 2) -= 48;}void function4(){	function3();}int main(){	function4();}

It "works" under gcc 3.3.1 and VisualC++ 7.1. The dodgy looking subtraction in function3 rewrites the return address on the stack to point into function foo. However, since the rewrite causes execution to jump into the same position relative to foo as it should have been relative to function4 (in both cases the jump is to just after the function call in the target function), and since foo and function4 are structurally equivalent, execution continues and returns from foo to main without a hitch. If you switch the order of functions foo and function2 the locations of the functions in memory changes and the stack rewrite now causes execution to jump into function2 and crash.

Obviously this is very dependant on compiler make, version and settings.

Enigma

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.