Advertisement

Seg Fault when trying to access function in shared_ptr

Started by April 12, 2017 09:39 PM
8 comments, last by frob 7 years, 8 months ago

Hi guys,

So I have a weird problem, so I have the following in a class


std::shared_ptr<gyroEngine::managers::InputManager> mp_inputManager;

...

void GyroEngine::startManagers() {
    mp_inputManager = std::make_shared<gyroEngine::managers::InputManager>(*this);
}

That is all fine and dandy, it seems to be working as is, I'm not getting any faults or anything from doing that and mp_inputManager is getting initialised.

Here's where my issue is. In my InputManager class I have:


void InputManager::handleEvents() {
    sf::Event event;
   
    while(mp_engine->getWindow()->pollEvent(event)) {
        switch(event.type) {

        ...

        }
    }
}

Which also seems ok. I have the following back in my GyroEngine class:


void GyroEngine::gameLoop() {
    while(mp_window->isOpen()) {
        mp_inputManager->handleEvents();
        update();
        render();
    }
}

Here is where it gets interesting. When I start the program, I instantly get a Segmentation Fault and it's coming from mp_inputManager->handleEvents(). I know this because just before I inserted that function into the gameLoop(), I'd written a handleEvents() function into GyroEngine.

My getWindow() function is as follows:


const std::shared_ptr<sf::RenderWindow> getWindow() const { return mp_renderWindow; }

What could be causing me to get this segfault?

Have you tried stepping through in a debugger? It sounds like one of the pointers is null or something -- stepping through should show exactly which line, and then you can work backwards from there -- why is it null, where should it be set, etc.

Hello to all my stalkers.

Advertisement

Have you tried stepping through in a debugger? It sounds like one of the pointers is null or something -- stepping through should show exactly which line, and then you can work backwards from there -- why is it null, where should it be set, etc.

It doesn't seem anything is null per say but I get the following in my InputManager class:


void InputManager::handleEvents() {
    sf::Event event;

    while(mp_engine->getWindow()->pollEvent(event)) { // <-- This is where it segfaults.
        switch(event.type) {
            case sf::Event::Closed:
                mp_engine->getWindow()->close();
                break;

             default: break;
         }
     }
}

It then kicks me to SFML's Window class to pollEvent(Event& event)?

When you call "mp_engine->getWindow()->close();", you are not exiting the while-loop. So depending on what close() does, it probably crashes when it tries to call pollEvent() on the closed() window. You can probably fix this by putting "return" instead of "break" in the sf::Event::Closed case.

When you call "mp_engine->getWindow()->close();", you are not exiting the while-loop. So depending on what close() does, it probably crashes when it tries to call pollEvent() on the closed() window. You can probably fix this by putting "return" instead of "break" in the sf::Event::Closed case.

Except that the closed() case should not be triggered until the "x" button is pressed on the window? I have however changed break; to return; and it still gives the above error.

while(mp_engine->getWindow()->pollEvent(event)) { // <-- This is where it segfaults.

This is where you use your debugger.

Is mp_engine null?

Is mp_engine->getWindow() returning null?

On many debuggers you can create a conditional breakpoint that will automatically test for those things each loop.

Also consider it possible that either the getWindow() or pollEvent functions() are crashing internally but they don't have debug symbols or they've been inlined so it appears to happen in that layer.

Advertisement

If you're using Microsoft Visual Studio I just found this:

https://blogs.msdn.microsoft.com/vcblog/2017/04/10/c-debugging-and-diagnostics/

I just skimmed it but it looks excellent for new people to coding and Visual Studios. Learn to use and love your debugger, you'll find your problems far faster then waiting on replies in most cases :)

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

If you're using Microsoft Visual Studio I just found this:

https://blogs.msdn.microsoft.com/vcblog/2017/04/10/c-debugging-and-diagnostics/

I just skimmed it but it looks excellent for new people to coding and Visual Studios. Learn to use and love your debugger, you'll find your problems far faster then waiting on replies in most cases :)

Using Netbeans 8.2

netbeans also has a debugger.

as frob said, see if mp_engine is null.

see if mp_engine->getWindow() is null.

Netbeans also supports conditional breakpoints, so you can set the thing to only break if either is null, then you can see the state at that moment before it dies.

This topic is closed to new replies.

Advertisement