Events causing crash

[sazzer]

I'm having some difficulty with wiring events up to actions. I've got a class that is responsible for the Main Menu scene in my program, which sets up the GUI interface and creates the wiring for the window to member functions in the class. The code for this is as follows(Event wiring copied directly from the Demo7 code):

Code: Select all

      void MainMenuScene::CreateScene(void)
      {
         CEGUI::WindowManager::getSingleton().loadWindowLayout((utf8*)"Media/Layouts/mainmenu.xml");
         CEGUI::System::getSingleton().getGUISheet()->addChildWindow((utf8*)"mainmenu");

         WindowManager::getSingleton().getWindow((utf8*)"Mainmenu/Quit")->
            subscribeEvent(PushButton::Clicked, boost::bind(&MainMenuScene::OnQuitButton,this,_1));

      }
      void MainMenuScene::OnQuitButton(const EventArgs& args)
      {
      }


Everything works absolutly fine, up until I actually click on the Quit button. When I do this, I get a Runtime error messagebox saying it "Requested the Runtime to terminate it in an unusual way"

If I do the following then it does exactly the same, with the same crash message and everything:

Code: Select all

Event::Subscriber es = boost::bind(&MainMenuScene::OnQuitButton,this,_1);
EventArgs e;
es(e);


And yet if I do it the even more direct way then it doesn't crash and does exactly what you would expect:

Code: Select all

EventArgs e;
boost::bind(&MainMenuScene::OnQuitButton,this,_1){e};


Can anyone see what the stupid mistake is here? I can't see anything at all wrong with it, except for the obvious fact that it doesn't work...
--
Graham

[CrazyEddie]

I assume there's nothing in CEGUI.log, so what you need to do is run the app within the debugger to discover what the exact error is (probably access violation or something), and where exactly it is happening (call stack); without this information there is no way of knowing where the failure is occurring, much less why.

[sazzer]

No - unfortunatly the last line of the log was the loading of MainMenu.xml - the crash happens before it can get logged it seems...

I was assuming(Read: hoping) that it was simply because of some call that I'd forgotten to make that was causing it, but if thats not the case then it's debugger time after work...
--
Graham

[CrazyEddie]

Your posted code looks good, so it must be some other strangeness going on. So I'm afraid it's going to have to be the debugger

[sazzer]

Well - I know what the problem is, but not why...
It seems that when the result of boost::bind is cast to an Event::Subscriber is turns into a null.

Stepping through the code tells me absolutly nothing - boost isn't the easiest code to read - but if I run the following code:

Code: Select all

void Quit() {}
...
boost::_bi::bind_t<void, void(__cdecl*)(void), boost::_bi::list0> bs = boost::bind(Quit);
Event::Subscriber es = bs;


Then bs is a perfectly usable variable for calling the Quit() function with, but es doesn't work at all...

Anyone else ever come across something as annoying as this? If so - what the hell do I do to stop it?
--
Graham

[CrazyEddie]

Well - I know what the problem is, but not why...
It seems that when the result of boost::bind is cast to an Event::Subscriber is turns into a null.

Stepping through the code tells me absolutly nothing - boost isn't the easiest code to read - but if I run the following code:

Code: Select all

void Quit() {}
...
boost::_bi::bind_t<void, void(__cdecl*)(void), boost::_bi::list0> bs = boost::bind(Quit);
Event::Subscriber es = bs;


Then bs is a perfectly usable variable for calling the Quit() function with, but es doesn't work at all...

Anyone else ever come across something as annoying as this? If so - what the hell do I do to stop it?
--
Graham

Event::Subscriber function signature is defined as:

Code: Select all

void function_name(const EventArgs& args);

Since the types in your example do not match then I would expect some kind of problem somewhere.

Some minimal code that exhibits the original problem might be useful, or a call stack at the point of the exception. Otherwise I'm in "crystal ball" mode and will have to start taking wild guesses or just saying it's a boost issue

Btw, which compiler is it again?

Thanks,

CE.

[CrazyEddie]

Sorry to say, but I got the same problem.

The gui code of our game works well on windows but doesn't work on linux. The cegui demo runs properly on both systems.

<snipped useful debug info, thanks>

This might be a pthreads/boost/hyperthreading problem so i will try with hyperthreading turned off... tomorrow, it's definitely time for bed now.

This definately seems like a threading problem of some type (basically due to the lockup with the mutex). I wouldn't be surprised if boost came into the equation, this is the cause of 75% of issues with the system

Let me know what happens in your tests with hyperthreading.

CE.

[sazzer]

Rewritten my test code to use a proper Event::Subscriber, and no difference:

Code: Select all

      void MainMenuScene::OnQuitButton(const EventArgs& args)
      {
      }
      void MainMenuScene::CreateScene(void)
      {
         boost::_bi::bind_t<
            void,
            boost::_mfi::mf1<
               void,
               MainMenuScene,
               const EventArgs&
            >,
            boost::_bi::list2<
            boost::_bi::list_av_2<
               MainMenuScene*,
               boost::arg<1>
            >::B1,
            boost::_bi::list_av_2<
               MainMenuScene*,
               boost::arg<1>
            >::B2
            >
         > bs = boost::bind(MainMenuScene::OnQuitButton, this, _1);
         Event::Subscriber es = bs;
         printf("Hello %p\n",es);
         printf("Hello %p\n",bs);
      }


(Note that if I make it so that OnQuitButton isn't in the MainMenuScene then it doesn't change anything )
As before, bs is a valid pointer to the function and es is just null...

The signature for bs is perfectly correct now - just spent 5 mins copying it from the compiler error to make sure

Compiler that I'm using is VC++7.1 (VS.NET2003), with everything - Boost included - from the dependencies package and no STLPort

@piet: No, I don't use ht or anything that fancy as yet. This is the most advanced thing I've come up against in this project so far and it's got me stumped, so ht isn't looking likely

[CrazyEddie]

@sazzer:
Thanks for the extra information. I did a small amount of poking about and I realised I'd made a minor error with the typedef for Subscriber So that makes the issue a CEGUI bug.

Anyway, I'm about to commit a fix to CVS, but since pserver access is down, here's a patch.

Code: Select all

Index: include/CEGUIEvent.h
===================================================================
RCS file: /cvsroot/crayzedsgui/cegui_mk2/include/CEGUIEvent.h,v
retrieving revision 1.5
diff -u -r1.5 CEGUIEvent.h
--- include/CEGUIEvent.h   10 Aug 2004 20:24:23 -0000   1.5
+++ include/CEGUIEvent.h   17 Aug 2004 09:13:42 -0000
@@ -62,7 +62,7 @@
 {
 public:
    typedef   boost::signal1<void, const EventArgs&>   Signal;         //!< Represents the internal signal object
-   typedef const Signal::slot_type               Subscriber;      //!< Function / object that can subscribe to an Event
+   typedef const Signal::slot_function_type      Subscriber;      //!< Function / object that can subscribe to an Event
    typedef Signal::group_type                  Group;         //!< Group for subscription (groups are called in ascending sequence)
    typedef boost::signals::connection            Connection;      //!< An object that is returned from subscribe function that can be used to control the connection / subscription.


I have tested this with code similar to what you posted and confirmed that when the assigned Event::Subscriber is invoked, the bound function is called as expected.

HTH

CE.

[CrazyEddie]

Hi piet,

I think that yours is definately a different issue to what sazzer had.

Could you post some minimal code that demonstrates the problem, including the event subscription / binding code and the signature of the handler / bound function. I'm sure that these are okay (since the handler call works), but it does help in the process of elimination.

I have a couple of things to do, and then I'll see if I can re-produce the problem on my linux box.

[CrazyEddie]

I wasn't able to reproduce the problem exactly

I have been investigating the issue, and it's definately related to threading issues. The main thing I came up with was that the demo apps (at least here) do not define _REENTRANT/BOOST_HAS_THREADS. Can you do a test and see what happens if you recompile your app and make sure that _REENTRANT and BOOST_HAS_THREADS are not defined (I understand that this may not be simple depending on what other libs you're using).

CE.