pollEvent -> Segmentation Fault

[eXpl0it3r]

If you had stated that you were using parts of the SmallGameEngine and shown the full code, we probably would've found out, what I just noticed when refactoring the code. Mainly there's a hugh bug in my code.

case sf::Keyboard::Escape:
        m_game.lastState();
        break;

This call is from inside the event loop and what it does, is pop the current state from the stack and resume the old one. This does sometimes, somehow work, but the problem is that the code after that call runs in an invalid object (i.e. the state was released by RAII). When now getting to the next iteration of the event while loop and trying to poll a new event from the event queue things blow up (sometimes), mostly because the locally declared sf::Event object gets destroyed with the state.

Well I have to think about how to get around this problem...

[eXpl0it3r]

Okay so I've fixed the problem, but I've also changed quite a bit of the naming convention, I also did merge the HandleEvent and Update functions, since I've never liked the idea of separating them and I gave the GameState base class directly a reference to the GameEngine, so there's no need to pass that thing around every draw/update call and it enables the possibility to work with the window information in the constructor/other functions.

Now for the fix, if you like to apply it to your engine as well:
I've added a new boolean variable to the GameEngine class m_resume and set it to false when initializing the class. Then I completely changed the lastState function:

void GameEngine::lastState()
{
    m_resume = true;
}

Thus the state does not get removed/deleted and the event loop and later the draw calls work properly.

And then I added to the nextState function in the beginning the following part:

    if(m_resume)
    {
        // cleanup the current state
        if ( !m_states.empty() )
        {
            m_states.pop();
        }

        // resume previous state
        if ( !m_states.empty() )
        {
            m_states.top()->resume();
        }

        m_resume = false;
    }

I hope that you really used parts of my code otherwise this all won't help you, but at least I got to fix more bugs on my end...

[mateandmetal]

My "engine" is not using parts of your code, so I must implement my own fix hahah 
I took a look at your code just to see how are you handling the events

So, this is a RAII problem 

This does sometimes, somehow work

That´s weird  The bug in my code had the same behavior

Why would the event queue be broken?

... trying to poll a new event from the event queue things blow up (sometimes), mostly because the locally declared sf::Event object gets destroyed with the state

Exactly

I also did merge the HandleEvent and Update functions

In a real game, particularly in the Play state, this can be a hell of a mess in one function :S

and I gave the GameState base class directly a reference to the GameEngine, so there's no need to pass that thing around every draw/update call

That´s what I do in my "engine" 
Now I think you should add an initialization function to your states, instead of loading files in the state constructor

I hope that you really used parts of my code otherwise this all won't help you

No, but I get the idea, thank you for sharing the fix.
The most important thing is not to break the event handling loop 

The guy that wrote the SDL tutorial doesn´t have this problem because he is using evil singletons   

[eXpl0it3r]

My "engine" is not using parts of your code, so I must implement my own fix hahah 
I took a look at your code just to see how are you handling the events

I see

I also did merge the HandleEvent and Update functions

In a real game, particularly in the Play state, this can be a hell of a mess in one function :S

That always depends on how you do things. But it makes more sense to tide them together since both are logical steps and one might depend on the other. I mean at one point one might want to handle user input over the event system but for another task one wants to use the directly sf::Mouse/sf::Keyboard classes, so where would one draw the line between event handling and updating?
If the one function gets too big one can always create new functions to wrap specific tasks.

Now I think you should add an initialization function to your states, instead of loading files in the state constructor

Well such a design pattern is actually against the whole purpose of a constructor and RAII. The only time I'd use a init function in C++03 would be when having multiple constructors which initialize the member variables equally, so one could prevent code repetition. With C++11 this problem doesn't exist anymore and one can just call the other constructor.
I'm not sure if we had this discussion already, but I'd still like to hear why you suggest to use a separate init function.

No, but I get the idea, thank you for sharing the fix.

Glad we could help each other.

The guy that wrote the SDL tutorial doesn´t have this problem because he is using evil singletons   

Yep.

[mateandmetal]

I'm not sure if we had this discussion already, but I'd still like to hear why you suggest to use a separate init function.

Well, loading files is something I definitely don´t want to happen in a constructor. File loading always can fail, so maybe you are constructing a "failed" object. Unless you throw an exception or set an error code on a global variable, you can´t notice, from another state function, that the loading failed. Maybe you see a white rectangle instead of the right texture, but what happens with different sound effects, even music? With luck, your game becames mute, and that is a bad thing for a game 

Unfortunately constructors can´t return a bool, so I do variables initialization and nothing more. When my "kind of engine" creates a new state, it calls the init function, and if something is wrong in there, I write a message on a log file and let the program have a creepy death  .. Well, I just set the "running" bool to false and the engine closes normally