Thread: Accessing virtual member function causes STATUS_ACCESS_VIOLATION to be thrown

I have a class that looks like this:

Code:

/* pdConState is going to be a base class */
	class pdConState
	{
                
		public:
		pdConState() { }
		virtual void ProcessUserInput(pdPlayer* ch);
		
	};

ProcessUserInput() is defined in another file.

Code:

void pdConState::ProcessUserInput(pdPlayer* ch)
{
/* Do stuff */
}

When I call it from somewhere else like this:

Code:

	for (int i = 0; i < player.size(); i++)
	{
		pdPlayer* ch=&player.at(i);
		if(ch->GetCmdBuffer()=="")
			continue;
		ch->GetState()->ProcessUserInput(ch);
	}

The program throws a segmentation fault / STATUS_ACCESS_VIOLATION when it hits the line in bold.

Code:

Program received signal SIGSEGV, Segmentation fault.
0x004047ac in pdmud::pdmudServer::ProcessInput (this=0x28cc78) at pdmud.cxx:111
111                     ch->GetState()->ProcessUserInput(ch);
(gdb) n
     12 [main] pdmud 1764 exception::handle: Exception: STATUS_ACCESS_VIOLATION
   1321 [main] pdmud 1764 open_stackdumpfile: Dumping stack trace to pdmud.exe.stackdum

However, making the function a plain function instead of a virtual one stops the crashing. After doing some Googling, I'm guessing that it has something to do with virtual functions being dynamically bound instead of statically bound, but I still have no idea of how to fix the problem.

You are probably doing something that results in undefined behaviour, but with the given information I cannot tell what that might be. Post the smallest and simplest compilable program that demonstrates the problem.

I think I found out what the problem was.
Changing the line that caused the crash to

Code:

ch->GetState()->pdConState::ProcessUserInput(ch);

makes the code work as expected.

I'm still trying to wrap my head around it, but I think the jist of the problem is that you need to suppress the virtual call mechanism if you want to call a virtual class defined in the base class. Or something. (It still doesn't really explain why the "demo" program I put in my last post works without it).

The explanation I am reading is at http://publib.boulder.ibm.com/infoce...ef/cplr139.htm.

Edited to quote the part of the above link I think is relevant:

If a function is declared virtual in its base class, you can still access it directly using the scope resolution (: operator. In this case, the virtual function call mechanism is suppressed and the function implementation defined in the base class is used. In addition, if you do not override a virtual member function in a derived class, a call to that function uses the function implementation defined in the base class.

Do you override ProcessUserInput in any derived class? Are you sure that the implementation of such an override is correct?

Originally Posted by EVOEx

Well, in that case the bold line wouldn't be the place of the crash but rather it would crash inside the called function. Also, adding "if(ch->GetState())" wouldn't stop the crash from happening.

That's true, but I am also looking to understand why Boxknife wants to declare the function virtual in the first place, and yet can freely "undeclare" its virtual aspect.

Boxknife, the problem is not even that the virtual keyword was useless there. I've written three examples to show you the actual problem. The cout's tell you what should have happened (it could've been comments, but now there's some more code). But this happens ON MY computer/compiler, but I reckon it will happen on most compilers:

First, your crashing example:

Code:

#include <iostream>

struct A {
	virtual void hello()
	{
		std::cout << "Never going to reach this!" << std::endl;
	}
};

A *getBadPointer()
{
	return NULL;
}

int main()
{
	getBadPointer()->hello();
}

I've explained two times already why this crashed. If you still don't get it, read my posts again. So now I added your hack fix, which doesn't crash (here, at least):

Code:

#include <iostream>

struct A {
	virtual void hello()
	{
		std::cout << "I'm not going to crash here!" << std::endl;
	}
};

A *getBadPointer()
{
	return NULL;
}

int main()
{
	getBadPointer()->A::hello();
}

I've also explained why this doesn't crash. Finally, however, I modify the hello function to show you that a simple change in the function DOES make it crash again:

Code:

#include <iostream>

struct A {
	int someVar;

	virtual void hello()
	{
		std::cout << "I'm still alive, but not for long!" << std::endl;
		someVar = 1;
		std::cout << "And I'll never even reach this code..." << std::endl;
	}
};

A *getBadPointer()
{
	return NULL;
}

int main()
{
	getBadPointer()->A::hello();
}

And that's the real problem with your "fix".


Anyways, yes, find out where the bad pointer comes from. If you need help, post the code where the "state" variable is assigned.


EDIT: YES, I *do* put the "*" for pointers next to the variable/function name rather than the type. I started out at C. And I still think it's more readable. Sue me.

Funnily enough, I'd forgotten to copy the state pointer in the copy constructor that was being used (though I'd gotten it in the regular constructor and the overloaded assignment operator - those were the first places I looked). I'd forgotten I'd even made one at all.

Also, just to be clear: yes, I understood you both times, and I appreciate your help.

Dereferencing a borked/NULL pointer was my first suspicion, but I mistakenly decided to look for other possible causes after checking what I thought were the class's only two constructors.

(Edited to finally post the code where the state variable is assigned) :3

Code:

	pdPlayer::pdPlayer(const pdPlayer& p):pdCharacter("", "", "", "", GENDER_N)
	{
		requestdisconnect=p.requestdisconnect;
		readbufferdirty=p.readbufferdirty;
		writebufferdirty=p.writebufferdirty;
		writebuffer=p.writebuffer;
		cmdbuffer=p.cmdbuffer;
		player_fd=p.player_fd;
		player_accepted=p.player_accepted;
		player_address=p.player_address;
+		state=p.state;
	}