FSM Assertions

[Nagilum]

New test build (SVN 6637) available for Mac OSX 10.6 on sourceforge.

I'm just testing the Linux build (asuming they all behave the same) I get these warnings on the console:

Code: Select all

freeorion: /usr/include/boost/cast.hpp:97: Target boost::polymorphic_downcast(Source*) [with Target = HumanClientFSM*; Source = boost::statechart::state_machine<HumanClientFSM, IntroMenu>]: Assertion `dynamic_cast<Target>(x) == x' failed.
Aborted

The game still appears to work just fine though. So nothing I should be concerned about then I assume?

[adrian_broher]

I get these warnings on the console

FYI: I get these error message since I started developing for FO.

[Dilvish]

same here; that's what I've always gotten from closing the game via the 'x' close button in the main window rather than menu->Resign.

[Nagilum]

FYI: I get these error message since I started developing for FO.

Ah, thanks! Then I'll release the Linux builds when ready.

[Geoff the Medio]

If you can figure out where the assert is that's producing that output, it would help figure out what's causing it.

[Nagilum]

Just doing some string matching from the message leads me to client/human/HumanClientFSM.cpp and this part:

Code: Select all

73 IntroMenu::~IntroMenu() {
74     if (TRACE_EXECUTION) Logger().debugStream() << "(HumanClientFSM) ~IntroMenu";
75     if (GetOptionsDB().Get<bool>("tech-demo"))
76         Client().Remove(Client().GetClientUI()->GetCombatWnd());
77 
78     Client().Remove(Client().GetClientUI()->GetIntroScreen());
79 }

That seems to be the only place (when only looking into .cpp files) where "HumanClientFSM" and "IntroMenu" show up together. So I guess there?

[Dilvish]

Just doing some string matching from the message leads me to client/human/HumanClientFSM.cpp ...That seems to be the only place (when only looking into .cpp files) where "HumanClientFSM" and "IntroMenu" show up together. So I guess there?

also looking at the .h files (specifically HumanClientFSM.h), you'll get a better match --

Code: Select all

struct HumanClientFSM : boost::statechart::state_machine<HumanClientFSM, IntroMenu> {
    typedef boost::statechart::state_machine<HumanClientFSM, IntroMenu> Base;
...

Which doesn't do near so much to narrow down the problem. It looks to me like our code itself doesn't ever use polymorphic_downcast on the human FSM, but that the boost statechart code does.

It's also looking to me like my recollection about when I get this message must be off, since I can't repeat it now. Something like it does still seem a possibility; I notice in the code that exiting the game via menu resets the HumanClientFSM, whereas just closing the appln window apparently does not. I'll pay more attn going forward.

[Nagilum]

It's also looking to me like my recollection about when I get this message must be off, since I can't repeat it now.

I simply start the game (fullscreen) and exit again (via the menu).

[cami]

The error message will only show up in debug builds. The mentioned assertion can only fail when a dynamic cast from boost::statechart::state_machine<HumanClientFSM, IntroMenu> to HumanClientFSM* fails. Unless we have any other classes deriving from boost::statechart::state_machine<HumanClientFSM, IntroMenu> (which wouldnt make much sense) the only situation I can think of that makes the cast fail is when we have code that only sees a forward declaration of HumanClientFSM, so it assumes HumanClientFSM and boost::statechart::state_machine<HumanClientFSM, IntroMenu> are unrelated types. Ensuring all *.cpp that use HumanClientFSM (possibly typedef'ed to a global or nested type, so need to check the *.h as well) also include the header defining HumanClientFSM (and not just a "class HumanClientFSM;") should resolve the issue IMHO.

[Geoff the Medio]

If someone who gets this message is so inclined, perhaps try adding

Code: Select all

#include "HumanClientFSM.h"

at line 8 of HumanClientApp.h and removing the "struct HumanClientFSM;" at line 17. If it's a forward declaration confusion issue, that might help...

Also, and independently, I'd like to know if changing this bit of code:

Code: Select all

void HumanClientApp::HandleWindowClose() {
    Logger().debugStream() << "HumanClientApp::HandleWindowClose()";
    EndGame(true);
    Exit(0);
}

by removing the "true" parameter to EndGame() makes any difference.

[Geoff the Medio]

bump?

[Dilvish]

bump?

AH yes, I was meaning to get to testing this, thanks for the reminder. I expect to do it today.

[Dilvish]

I decided to go ahead and get it done. Unfortunately, neither change helped.

[Geoff the Medio]

Try moving

Code: Select all

    EndGame();
    Exit(0);

into HumanClientApp::HandleWindowClosing() just above?

[Dilvish]

Try ...

nope, not that either.