Crash in Program Crash

[hailstone]

Using a malformed xml we can get it to crash. I think when the exit button is then clicked the dch (in Windows) is deleted. program then goes out of scope and is destructed. It gets to delete preCrashState; and gets an assertion error in gl_wrap.h

Code: [Select]

void swapBuffers() {
int swapErr = SwapBuffers(dch);
assert(swapErr);
}
This is happening in Windows with the latest GAE trunk. I think it could also be happening on Linux too. Commenting out the delete line causes it to exit as expected.

OK I think I know what's happening.

The previous state is saved which happens to be the 'game' state. When this state tries to be deleted it tries to print a message to the screen with the logger but the window with the context has already been destroyed so it crashes with the assertion error.

There seems to be a problem with the group selection patch I recently stuck in too which somehow only happens when it crashes. Anyway it's late now so I'll have a look at it more another time or if someone else wants to give it a go.

EDIT: also I think I found a few lines of code that aren't needed like in crash it runs a loop around the same loop and restoring video mode in the catch blocks when program does that when it destructs.

[assassin]

Just to confirm, this bug does happen in linux.

[silnarm]

Commenting out the delete line causes it to exit as expected.

Maybe try swapping the order they are released, delete preCrashState state first then programState. Obviously commenting out delete statements isn't the ideal solution

The previous state is saved which happens to be the 'game' state. When this state tries to be deleted it tries to print a message to the screen with the logger but the window with the context has already been destroyed so it crashes with the assertion error.

It would indeed appear the program is still looping after things have been released... this all a bit complicated by the platform specific stuff... I've had a quick look, but this will take some investigating I suspect, one thing I have noticed though, WindowGl::context doesn't seem to ever have it's end() method called, which may be related...

[hailstone]

If you put a breakpoint (in VS) in Game's destructor and then find dch in program (hover over program in Game's constructor). It says error because the window was destroyed (and it's got the context attached to it) when you press the exit button in crash (I assume anyway). I think this could be fixed by moving the rendering stuff out of the destructor and into a Game::end() method and calling that only when you exit from the game state not the crash state.

[silnarm]

If you put a breakpoint (in VS) in Game's destructor and then find dch in program (hover over program in Game's constructor). It says error because the window was destroyed (and it's got the context attached to it) when you press the exit button in crash (I assume anyway). I think this could be fixed by moving the rendering stuff out of the destructor and into a Game::end() method and calling that only when you exit from the game state not the crash state.

Right you are... but I think the best solution would be to just remove the render to screen,
so

Code: [Select]

logger.add("Game", true);becomes

Code: [Select]

logger.add("Game");
I don't think we need that super-informative message rendered to the screen

[hailstone]

We could do that but then we'd also need to change it in World::end() too, maybe in other places and if we wanted to render something else in the future it wouldn't be possible. There's a few things we could do, but I'll need to think about it more.

EDIT: the previous state that is stored is only a flag for checking if the state has already crashed. I'm not sure if Daniel was going to do something else with it but there's no reason to have it there at the moment. So if we replace it with a bool and delete game before starting crashed state it should fix things. Using gui in Selection::update() for centering on units is still a problem but seems only when in crashed state.

EDIT2: The reason why the gui in Selection doesn't work when crashed is because Game throws an exception before Game::init() is callled (which goes all the way down to Selection::init(Gui *gui, int factionIndex)). Checking that gui is not null before using it works but I don't think this is an ideal solution since it needs to be check every time it is used in one of the methods that's called in Game::~Game().

Changes have been committed to trunk.