next »

[Glaiel-Gamer]

Just thinking here.

In making my game, there are a few times when the game simply freezes with no message, no warning, and it's pretty bad in fullscreen since that requires restarting my computer to get out of it. I'm doing my best to resolve these issues, and I know that the ideal situation would have to be not having this happen at all (what I'm shooting for). But I realize there's a chance some odd bug might slip through undetected, or even during testing a freeze in full screen requiring a restart might kill any chances of me getting a log as to what happened there.

Would it be worth it to launch the game in a separate thread, then continually have it report back every time it's rendered a frame, that way I can detect a freeze and force-kill the game?

[Alex May]

Why does it mean you have to restart? You mean it locks up the keyboard as well? You can't task-switch out?

[Glaiel-Gamer]

Why does it mean you have to restart? You mean it locks up the keyboard as well? You can't task-switch out?

ya in fullscreen, at least on my mac, it's fullscreen and the force-quit menu pops up under the game

I've had stuff like that happen on windows too, but not this specific game (since I havent done much windows testing on it yet)

[mcc]

Hm, would you happen to be doing this in SDL for mac? (If so the particularly sinister thing here is, if an SDL full screen game on mac freezes you can just bang the "force quit" keystrokes and the OS will eventually realize the program is not responding to events and kill it... but if an SDL full screen game on the mac crashes, and you're running in xcode... it launches the debugger, but the game is still full screen so you can't see the debugger, but the debugger has taken over so the close-on-freeze feature in the OS... it's a kind of nasty little bug in SDL. The only solutions I found were (1) switch to windowed mode every time I'm testing a feature with any chance of crashing or (2) ssh into the mac from another computer and kill -9 xcode...)

Anyway I think your idea is actually a pretty good one, and you can after all set it up to conditionally compile so that it occurs only in DEBUG mode. I know such a feature would have been useful to me the last program I did. (Of course if you are getting the sdl/xcode bug above I'm not sure whether your thread trick will save you, since the debugger is likely to halt your watchdog thread...?)

EDIT: "ya in fullscreen, at least on my mac, it's fullscreen and the force-quit menu pops up under the game" .. Oh, huh. Yeah, I don't think those are freezes, I think those are crashes.

[Average Software]

ya in fullscreen, at least on my mac, it's fullscreen and the force-quit menu pops up under the game

I had this problem too, and what causes it is that Xcode is transferring control to the debugger when your program dies.

There's a switch somewhere in Xcode that will prevent this from happening, and then when your program dies in fullscreen it will really die and you won't have to go restarting.  I can't remember exactly where the setting is, I think it's somewhere in the program preferences.

[Glaiel-Gamer]

I don't develop in debug mode unless I'm at a complete loss trying to figure out the problem in release mode


Where's this switch?

[Glaiel-Gamer]

worked quite well actually

class Signal {
  private:
    SDL_cond * conditional;
    SDL_mutex * mutex;
  public:
    Signal();
    void send(); //sends a signal
    void wait(); //waits for a signal to be recieved
    bool wait(int ms); //waits a certain time for a signal to be recieved
    ~Signal();
};

Thread monitorThread;
Signal timeout;
bool ALIVE = true;

int monitor(void * args){
  while(true){
    if(!timeout.wait(5000)){
      if(!ALIVE) break;
      std::cout << "Game Froze" << std::endl;
      exit(0);
    }
  }
  return 0;
}

void NoFreezeInit(){
  monitorThread.spawn(monitor);
}
void StillAlive(){
  timeout.send();
}
void NoLongerAlive(){
  ALIVE = false;
  timeout.send();
}

int main(int argc, char *argv[]){
 
  NoFreezeInit();
...
}

then every frame I just call "StillAlive" and the monitor thread won't have to shoot the main thread in the face

I might just keep this in there, you know just in case someone does something stupid like load a level with 4000000 objects in it

[Average Software]

I don't develop in debug mode unless I'm at a complete loss trying to figure out the problem in release mode


Where's this switch?

Look at the properties for the executable, under the "Debugging" tab.  There's a checkbox labelled "Auto-attach debugger on crash"

[Klaim]

Just some known things about game developement on PC/Mac :

 - develop your game in windowed mode, don't use debugging in fullscreen until you really have too - I too have this need somtime;
 - use 2 screens : one with the debugger, the other with the game running full screen - you get the best combo that way.

And if your game freeze but don't crash, often it can be an infinite loop, so switch to the debugger and break, see what it does. It can also be recursive call but that one will crash some time later once the call stack is full.

[Impossible]

- develop your game in windowed mode, don't use debugging in fullscreen until you really have too - I too have this need somtime;
 - use 2 screens : one with the debugger, the other with the game running full screen - you get the best combo that way.

This is usually the standard answer to this problem . Glaiel's solution of having another thread monitor the health of the game thread is... clever...