Stack Overflow, but allocating on the heap...

[LN7oGNh0]

Hello, Im getting this error when I type this: p = new Player(window, clock, windowEvent, view);. This is allocating on the heap, correct? So, why would something like this occur? Also, there are many other pointers in the program that resemble this, so could this be causing the error? I am using SFML 2.0 also.

[Zhuge]

You haven't given enough information for us to figure out your problem. Try to give the minimal amount of code that reproduces the problem.

If I were to guess, I'd say the problem is elsewhere before that line, and the issue only becomes apparent later thanks to undefined behavior.

[N36fSL3A]

By just guessing, I'm assuming the problem is that you're trying to set a object equal to a pointer.

So what you're doing is this:

Player p;

p = new Player(window, clock, windowEvent, view);

instead of this:

Player* p;

p = new Player(window, clock, windowEvent, view);

// Don't forget to delete allocated memory
delete p;

[Null]

could you post class Player code?

@Fredbill30: your first example doesn't compile so the problem is somewhere else

[AbstractionAnon]

As Zhuge said, you haven't given us enough information.

My guess is some type of unintentionional recursion.
Do you have assignment operators that are being overloaded?

[LN7oGNh0]

I think Anon is correct, there are multiple files and two of them (Player and Enemy) include each other. These are the header files:

#ifndef PLAYER_H
#define PLAYER_H

#include <fstream>

class Enemy;

class Player 
{
private:
	sf::RenderWindow& window;
	sf::Event& windowEvent;
	sf::Clock& clock;
	sf::View& view;

	int lives;
	float topSpeed;
	float jumpSpeed;
	float jumpAccel;
	float accel;
	float speed;
	float yVelocity;
	bool jumping;
	bool dead;

	Enemy* en;
public:
	Player(sf::RenderWindow& window, sf::Clock& clock, sf::Event& windowEvent, sf::View& view);
	~Player();

	float rightSide;
	float leftSide;
	float bottom;
	float top;

	sf::RectangleShape player;
	
	bool rightCollide;
	bool leftCollide;
	std::ofstream file;
	bool bottomCollide;
	bool topCollide;

	sf::Vector2f pos;
	sf::Vector2f po;

	void updatePos(float& leftSide, float& rightSide, float& bottom, float& top);
	void manageStats();
	void walk(float& speed, float& accel, bool& rightCollide);
	void jump();
	void update();
	void render();
};

#endif PLAYER_H 

#ifndef ENEMY_H
#define ENEMY_H

class Player;

class Enemy 
{
private:	
	sf::RenderWindow& window;
	sf::Clock& clock;
	sf::Event& windowEvent;
	sf::View& view;

        Player* p;
	
	float topSpeed;
        float speed;
public:
	Enemy(sf::RenderWindow& window, sf::Clock& clock, sf::Event& windowEvent, sf::View& view);
	
	sf::RectangleShape enemy;
	
	float leftSide;
	float rightSide;
	float top;
	float bottom;

        void follow(); 
	void moveLeft();
	void moveRight();
	void stand();
	void updatePos(float& leftSide, float& rightSide, float& bottom, float& top);
	void update();
	void render();
};

#endif ENEMY_H 

I can also provide the .cpp files if needed. Also, if it helps, when the error occurs, there is a variable called size which is an unsigned int of 236... It comes up in the small area where the 'locals' menu tab is. (I am using VC++ 2010).

EDIT: There are also many other files, one is called World and contains pointers to both class Enemy and Player. And there is another called Game which contains a pointer to World.

EDIT #2: Lastly, file opens called 'malloc.c'. This is the function that is shown:

__forceinline void * __cdecl _heap_alloc (size_t size)

{

    if (_crtheap == 0) {
        _FF_MSGBANNER();    /* write run-time error banner */
        _NMSG_WRITE(_RT_CRT_NOTINIT);  /* write message */
        __crtExitProcess(255);  /* normally _exit(255) */
    }

    return HeapAlloc(_crtheap, 0, size ? size : 1);
}

Hopefully that elps in some way.

[ne555]

> p = new Player(window, clock, windowEvent, view);
> Also, there are many other pointers in the program that resemble this
I doubt that you have a good reason for that. ¿why don't simply create objects?


At least give us a backtrace.

[LN7oGNh0]

Sorry if the game design sounds really flawed (its my first game). There are different files for many classes, so sometimes another object in a different file needs to access it. for example, the World class checks collision between player and enemy, and because it is in a different class, I decided to use pointers. I dont know if this game design is bad, but I just sort of 'go with it'.

Anyway, Ive sort of solved my problem. The World .cpp file included player.h, and enemy.h. I swapped enemy.h so that it was on top of player.h, and then removed a pointer in the player class which pointed to the enemy class. Then the pointer in the enemy class did not cause any stack overflows. But, I still dont understand why I cant have both of these pointers.

[N36fSL3A]

@Null

That was the point...

@Hazique
Sorry to say this, but your best bet would be to redesign this on paper, then try to recreate your classes with your new design.

I'm not saying rewrite it from scratch, keep as much code needed and redesign.

EDIT - The way I'm solving this in my game is by making a Player class and NPC class (There's no Enemy class, NPCs can be enemies, neutral, or allies) derive from a Unit base class. The classes are basically identical, there are some cases where the code is exactly the same from both classes, so why not that?

[ne555]

¿what point? OP has a runtime error, its code compiled.

> I swapped enemy.h so that it was on top of player.h
that should have no effect

> Then the pointer in the enemy class did not cause any stack overflows
... ¿are you sure that the problem was `stack overflow?
Maybe it was simply `segmentation fault'. Probably your links are incorrect (the pointers are pointing to garbage)

Run through a debugger, see the exact line where the crash occurs and go up

[LN7oGNh0]

Hey! Thats a good idea! But im still confused about all this. Lots of people advise using different header files and cpp files to make the code more organised, but doesnt this end up in more function recursion? At the moment, every class has an update and render function which cdraws and calls other functions such as the move function, and then the next class has it's own update and render function which called those until it reaches the game class where it is called for a final time. But why would creating a pointer make the stack overflowed? Isnt this all allocated on the heap?

[N36fSL3A]

No. Don't have units own other units.

This can be easily solved by having a unit manager class

class UnitManager
{
    // The functions should be exactly the same as the functions in both classes. 
    // Just have a for loop to go through them
    
    private:
        std::vector<NPC*> npcs;
        std::vector<Player*> player;
};

Then, each would update independently.

Updating would look like:

for(unsigned int n = 0; n < npcs.size(); n++ )
{
    npcs[n]->Render();
}

same with player

[LN7oGNh0]

Wow. Cant believe I didnt think of that! Thank you very much, I will be sure to use it. Hopefully I will never have to deal with stack overflow again...

[N36fSL3A]

If you're dealing with multiple maps, like I am, I'm writing a command system that each map requires, and it loads a "command file" from each map area, and that loads required "non-map" objects. Basically a bare-bones scripting system.

[LN7oGNh0]

I am not familiar with the term map in game programming. Are you saying the map is the level...? Then the non map objects would be things that would just make it look better, like rocks and trees... I think Ive heard of what you are saying, but I think it was referred to as a 'level editor'. This was a GUI, instead of a command system as you said. I might just consider a command system because it would take a lot less time than making a whole GUI just to load the level and different objects.

[N36fSL3A]

No, Rocks and trees would be part of the map, unless you want the player to interact with them.

I don't mean a level editor, as you aren't using a graphics library (which once you're done with this I strongly recommend you do(it isn't that much harder))

By map I mean the level. Map doesn't necessarily have to be graphical, each coordinate can hold a special thing the player can do.

Example:

class Map
{
    Coord getX() {return X;}
    Coord getY() {return Y;}

    public:
        // I'd make each coordinate an object of the "Coord" class, which has a container of enemies
        Coord coord x, y;
        coord
};

Then make an object and return it to the player, manipulate the data however you'd like.

[LN7oGNh0]

Oh, i see. Anyway, I am using a graphicl library already (SFML). Ok, thanks for your help.