pollEvent -> Segmentation Fault

[mateandmetal]

Hi

The fault that my game has becomes randomly. Most of the times it works well, but sometimes it crashes 
Here is some code

// main.cpp
// while engine is running...
while (Engine.estaCorriendo()) {

   Engine.manejarEventos(); // handle events
   Engine.actualizar(); // update
   Engine.dibujar(); // draw

} // while


// The engine cpp file..
void Implacable::manejarEventos() {

    // Call handle events function of the last state
    misEstados.back()->manejarEventos();

}


// The intro state cpp file
void ige::Intro::manejarEventos () {

    sf::Event evento;

    // engine.getWindow() returns a reference to the sf::RenderWindow
    while (elMotor.obtVentana().pollEvent (evento)) {

        switch (evento.type) {

            // Cerrar ventana: salir
            case sf::Event::Closed:

                elMotor.salir(); // set the engine running to false
                break;

            // Any pressed event: Go to the menu state
            case sf::Event::KeyPressed:
            case sf::Event::MouseButtonPressed:
            case sf::Event::JoystickButtonPressed:

                elMotor.cambiarEstado <ige::Menu> ();
                break;

            default:
                break;

        } // sw

    } // while

}
 

This is what I get from the debugger

#0 00459524     sf::Window::pollEvent(this=0x41a00010, event=...) (E:\Programacion\SFML2\src\SFML\Window\Window.cpp:183)
#1 0040233D     ige::Intro::manejarEventos(this=0x68d7b0) (E:\Programacion\Ratalypsis\IGE-ESTADOS\Intro.cpp:108)
#2 00401423     Implacable::manejarEventos(this=0x28fbf8) (E:\Programacion\Ratalypsis\IGE-ESTADOS\Implacable.cpp:42)
#3 00402A74     main() (E:\Programacion\Ratalypsis\main.cpp:24)
 

My debugger points to line 183 of SFML Window code

////////////////////////////////////////////////////////////
bool Window::pollEvent(Event& event)
{
    if (m_impl && m_impl->popEvent(event, false)) ----> SEGFAULT HERE
    {
        return filterEvent(event);
    }
    else
    {
        return false;
    }
}
 

This happens sometimes when I press a key or mouse button.

I never had problems with the minimum code of the example tutorials. I´m using MingW32/gcc 4.7.0 (official build), Code::Blocks SVN, Win 7 x64, recent version of SFML2 compiled by me, static linking

I didnt find something similar in the forum/GitHub issues page.

[Laurent]

What does elMotor.cambiarEstado <ige::Menu> () do?

[eXpl0it3r]

Y U NO USE ENGLISH!
Actually it's funny how usually everyone programs in English, then again it makes sense, since the easiest accessible sources are also in English and many willing people for helping also speak English.

Does it also happen with a normal example (i.e. without your engine aka elMotor )?

[mateandmetal]

What does elMotor.cambiarEstado <ige::Menu> () do?

elMotor is a reference to the state manager. My state manager has this private data:

typedef   std::unique_ptr <ige::IEstadoJuego>       estadoPtr; // unique pointers of game states
std::vector <estadoPtr>         misEstados;
 

This is how I store my gamestates. And this is the code I wrote to change the game state:

template <class T_Estado>
void Implacable::cambiarEstado () {

    // If the vector is not empty, clean previous state
    if (!misEstados.empty()) {

        misEstados.back()->limpiar(); // clean function, stops music, blabla..
        misEstados.pop_back();

    } //if

    // Create the new state
    misEstados.push_back (estadoPtr (new T_Estado (*this)));

    // Initialize the new state
    misEstados.back()->iniciar();

}
 

Y U NO USE ENGLISH!

LOL 

Actually it's funny how usually everyone programs in English

Yes, why people do that? 

Does it also happen with a normal example (i.e. without your engine aka elMotor )?

No, the normal example works fine

[Laurent]

The problem is most likely inside elMotor.cambiarEstado<ige::Menu>(); (it works if you comment it out, right?), so you should have a look at what happens inside (in the cleanup function of the previous state, or in the init of the next one). My guess is that the state switch invalidates the window instance.

[mateandmetal]

(it works if you comment it out, right?)

Right.

so you should have a look at what happens inside (in the cleanup function of the previous state, or in the init of the next one). My guess is that the state switch invalidates the window instance.

The clean function of the first state is doing nothing. The init of the second one, creates a circle, just to test.

I don´t know why the window is feeling invalidated. I have a sf::RenderWindow object and I keep it alive inside my state manager. In the state manager .hpp file I´m doing this

#include <SFML/Graphics/RenderWindow.hpp>
...
public:
sf::RenderWindow &obtVentana () { return miVentana; } //getter
...
private:
sf::RenderWindow miVentana;
 

So each state must use

#include <SFML/Window/Event.hpp>
 

Is that wrong? 
If I add this to the state manager:

#include <SFML/Window.hpp>
 

I get another beautiful piece of data from the debugger:

#0 004D5426     std::operator==<sf::Event, sf::Event&, sf::Event*>(__x=..., __y=...) (e:/programacion/mingw/bin/../lib/gcc/mingw32/4.7.0/include/c++/bits/stl_deque.h:250)
#1 004C50CD     std::deque<sf::Event, std::allocator<sf::Event> >::empty(this=0x2974d67b) (e:/programacion/mingw/bin/../lib/gcc/mingw32/4.7.0/include/c++/bits/stl_deque.h:1210)
#2 004C50E3     std::queue<sf::Event, std::deque<sf::Event, std::allocator<sf::Event> > >::empty(this=0x2974d67b) (e:/programacion/mingw/bin/../lib/gcc/mingw32/4.7.0/include/c++/bits/stl_queue.h:150)
#3 004BA4AD     sf::priv::WindowImpl::popEvent(this=0x2974d677, event=..., block=false) (E:\Programacion\SFML2\src\SFML\Window\WindowImpl.cpp:100)
#4 004B977E     sf::Window::pollEvent(this=0x74d226e9, event=...) (E:\Programacion\SFML2\src\SFML\Window\Window.cpp:183)
#5 00401909     ige::Intro::manejarEventos(this=0x82d828) (E:\Programacion\Ratalypsis\IGE-ESTADOS\Intro.cpp:108)
#6 00402673     Implacable::manejarEventos(this=0x28fbf8) (E:\Programacion\Ratalypsis\IGE-ESTADOS\Implacable.cpp:42)
#7 00402510     main() (E:\Programacion\Ratalypsis\main.cpp:24)
 

It seems I have a serious events problem, but I don´t know how to fix it   
What can I do? (I don´t have the money to buy a Unreal Engine licence  )

[Laurent]

Sometimes it's just impossible to debug code just by staring at it. So if I had to fix this bug, what I'd do is to write a complete and minimal example that reproduces the problem. Take from your program only what's needed to reproduce the problem, take the code out of the classes/functions and write a simple main() with everything inside. Then the bug will appear clearly

[mateandmetal]

Ok, I found the bug and fixed it 

I replaced the classic while (pollEvent) with if (pollEvent). Is this a good/clean way to fix it?

[Laurent]

Of course not

You didn't find the cause of the problem, and don't know why your "fix" solves it. So it's even worst in my opinion, now you possibly have a hidden problem that may pop out one day.

[eXpl0it3r]

I replaced the classic while (pollEvent) with if (pollEvent). Is this a good/clean way to fix it?

This probably won't fix anything, but just hide it a bit more...
Also now you have the problem that when more events get triggered for one frame, your event queue slowly fills up. One should mostly always handle the events with a while-loop. Besides the only difference between while and if is that the while loop walks through all the events, where as the if just polls one event.
So no it's not a good/clean way, if any.

You should really make a minimal example or at least show the whole source...

[mateandmetal]

You didn't find the cause of the problem

Looking at my latest debug information, I think I understand the cause. I´m deleting the last game state, in the middle of the event management, so maybe I´m breaking the event queue or something like that, right?. I need to find a way to change the game states AFTER the event management function. I will try to fix that.

One should mostly always handle the events with a while-loop

Taking a quick look at your "SmallGameEngine" code:

void IntroState::HandleEvents( GameEngine& game )
{
        sf::Event event;

        if( game.screen.pollEvent( event ) )
 

Ooops! 

[Laurent]

Looking at my latest debug information, I think I understand the cause. I´m deleting the last game state, in the middle of the event management, so maybe I´m breaking the event queue or something like that, right?

Why would the event queue be broken? As long as you don't touch the window, nothing happens to it.

[eXpl0it3r]

One should mostly always handle the events with a while-loop

Taking a quick look at your "SmallGameEngine" code:

void IntroState::HandleEvents( GameEngine& game )
{
        sf::Event event;

        if( game.screen.pollEvent( event ) )
 

Ooops! 

Yes that's really an Ooops!
This mistake happened because I just rewrote the whole engine by using the old SDL/C-ish code underneath. I'm not sure if it's really wise in SDL to just check with if or if it's another 'mistake' in the original tutorial:

void CIntroState::HandleEvents(CGameEngine* game)
{
        SDL_Event event;

        if (SDL_PollEvent(&event)) {
                switch (event.type) {
                        case SDL_QUIT:
                                game->Quit();
                                break;

                        case SDL_KEYDOWN:
                                switch (event.key.keysym.sym) {
                                        case SDLK_SPACE:
                                                game->ChangeState( CPlayState::Instance() );
                                                break;

                                        case SDLK_ESCAPE:
                                                game->Quit();
                                                break;
                                }
                                break;
                }
        }
}

Thanks for pointing that out, I'll change it as soon as I find the time.

[mateandmetal]

Why would the event queue be broken?

I thought the event queue may be broken because of this debug information

#0 004D5426     std::operator==<sf::Event, sf::Event&, sf::Event*>(__x=..., __y=...) (e:/programacion/mingw/bin/../lib/gcc/mingw32/4.7.0/include/c++/bits/stl_deque.h:250)
#1 004C50CD     std::deque<sf::Event, std::allocator<sf::Event> >::empty(this=0x2974d67b) (e:/programacion/mingw/bin/../lib/gcc/mingw32/4.7.0/include/c++/bits/stl_deque.h:1210)
#2 004C50E3     std::queue<sf::Event, std::deque<sf::Event, std::allocator<sf::Event> > >::empty(this=0x2974d67b) (e:/programacion/mingw/bin/../lib/gcc/mingw32/4.7.0/include/c++/bits/stl_queue.h:150)
 

Nevermind, I found a clean fix now 

void ige::Intro::manejarEventos () {

    sf::Event evento;
    bool cambiarEstado = false;

     while (elMotor.obtVentana().pollEvent (evento)) {

        switch (evento.type) {
            case sf::Event::Closed:

                elMotor.salir();
                break;

            case sf::Event::KeyPressed:
            case sf::Event::MouseButtonPressed:
            case sf::Event::JoystickButtonPressed:

                cambiarEstado = true;
                break;

            default:
                break;
        } // sw

    } // while

    // Fix
    if (cambiarEstado) {
        elMotor.cambiarEstado <ige::Menu> (); // After the events processing loop
    } // if

}
 

It works perfectly now. Thank you for the responses Laurent, Exploiter

Thanks for pointing that out, I'll change it as soon as I find the time.

Glad to help 

[Laurent]

Nevermind, I found a clean fix now

But you still don't know what the problem was. So it might come back one day.