Crash on ProgressBar

[westpointer]

I tried to use CEGUI::ProgressBar in OGRE to show the progress of loading resources. But it crashed when progressing finished:

---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: e:\Ogre Projects\Test\Bin\Debug\Test.exe
File: e:\vstudio8\vc\include\xtree
Line: 370

Expression: map/set iterator not incrementable

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

Anybody knows what the problem is? Thanks in advance.

[CrazyEddie]

Hi, and welcome.

You're going to have to post some code, and also indicate where in this code the issue arises by posting a callstack or something.

Now, I'm going to rant. Please don't take this personally, but this has been building for a few days, and now I'm going to let it out

I do not understand why people keep posting questions and expecting anybody to know what could cause an issue when no relevant information is posted. Perhaps you could enlighten me? Based on the information you have posted - an assertion failure within the STL- what do you think we are able to deduce? I'll tell you what we are able to deduce, absolutely nothing. You might as well have posted the single line, "It doesn't work, why?" as it contains about the same level of useful information. When you guys post messages like this all you are doing is wasting our time, and wasting your own time, since all we're going to do is come on here and ask for more information - if you posted that information to start with (which we already ask you to do), you'd likely get quicker and more relevant answers. Instead of that, you have me coming on here and moaning

CE

[westpointer]

Maybe I need to give more info about it. Here is the situation:

I have a main menu with "Start" push button on it. When I click "start", the loading sheet with a progressbar on it appears, after finish loading,
the loading sheet is destroyed, then scene should be shown, but it crashed and appears the above.
Before I added loadingbar code into resource loading function, everything is just fine.

[CrazyEddie]

I give up. Truly, I do.

[westpointer]

I am a newbie, sorry for my ignorance. I posted my second post without knowing your first reply
I searched the forum but did not find a similar problem. And the
CEGUI.log show no error or exception. My code snippet：
For responding “start” button：

Code: Select all

bool MainMenuDlg::handleLaunchOnClick(const CEGUI::EventArgs &args)
{
   SimulatorStateManager::getSingletonPtr()->requestStateChange(LOADING);
   Simulator::getSingletonPtr()->loadSceneResources();
   
   SimulatorStateManager::getSingletonPtr()->requestStateChange(SIMULATION);

   return true;
}


loadSceneResources()：

Code: Select all

void Simulator::loadSceneResources(void)
{
   LoadingBar* mLoadingBar = new LoadingBar();
   mLoadingBar->start(mRenderWindow, 1, 1, 1);
   Ogre::ResourceGroupManager::getSingleton().initialiseResourceGroup("Scene");
   mLoadingBar->finish();
   delete mLoadingBar;
}


In function start(mRenderWindow, 1, 1, 1), I load a loading gui sheet, and In finish() I destroy it. And the "map/set iterator not incrementable" problem comes from ceguimemeberfunctionslot.h Does it clear enough?

[CrazyEddie]

Hi,

I have a suspicion that parts of the system are getting deleted from underneath itself, from within Simulator::loadSceneResources, which is called from within an event handler (what this means essentially is that the iterator that controls what functions get called is being invalidated by the underlying collection changing size, then when we do ++iterator, it tries to advance beyond the end(), hence the assert. You should not, for example, subscribe or disconnect from event "X" within a handler for the same event "X").

Which line within Simulator::loadSceneResources does the assert get caused? Whichever function it turns out to be, can you post that code also?

CE.

[CrazyEddie]

I thought about this a bit more while I was out this afternoon, and would I be right in saying the assert actually happens upon return from MainMenuDlg::handleLaunchOnClick? If that's the case, then it's definitely related to the event handlers attached to the start button getting clobbered somehow.

CE

PS. Don't take my earlier 'bad attitude' to heart, just put it down to part of CE's eccentricity; most users who have been around here for a while would probably tell you just to ignore it completely

[westpointer]

CE, I completely understand, It is just all my fault. I can't reply until now, cause the time lag.

The assert is not caused in Simulator::loadSceneResources, This assert comes out when MainMenuDlg::handleLaunchOnClick returns true and steps into ceguimemeberfunctionslot.h:

Code: Select all

template<typename T>
class MemberFunctionSlot : public SlotFunctorBase
{
public:
    //! Member function slot type.
    typedef bool(T::*MemberFunctionType)(const EventArgs&);

    MemberFunctionSlot(MemberFunctionType func, T* obj) :
        d_function(func),
        d_object(obj)
    {}

    virtual bool operator()(const EventArgs& args)
    {
       return (d_object->*d_function)(args);
    }

private:
    MemberFunctionType d_function;
    T* d_object;
};


The assertion come out from this line:

Code: Select all

return (d_object->*d_function)(args);


It tells me that no source code available in current position, So I can't trace into it. And the corresponding Auto window shows:


But when I delete loadingbar code snippet, the Auto window shows like this:

See the difference? Can this help to figure out the problem?

PS:

it's definitely related to the event handlers attached to the start button getting clobbered somehow.

I do not quite get what you mean, and how can this happen?

[dmail]

it's definitely related to the event handlers attached to the start button getting clobbered somehow.

I do not quite get what you mean, and how can this happen?

The object pointer d_object has been deleted yet you still have the handler associated with the functor. You can see this by the hex value 0xcdcdcdcd which is mscv's way of telling you of the error in debug mode. If it had been 0xcccccccc then it had not been initialised. (other compilers sometimes use different values such as 0xDEADBEEF etc)

[CrazyEddie]

As dmail says, something is getting deleted when it shouldn't be - this is likely to be happening in either LoadingBar::finish or LoadingBar::~LoadingBar.

[westpointer]

Here is my LoadingBar::finish and LoadingBar::~LoadingBar:

Code: Select all

LoadingBar::~LoadingBar(){}

void LoadingBar::finish(void)
{
   // Destroy loading dialog
   if ( CEGUI::WindowManager::getSingleton().isWindowPresent("LoadingDialog") )
   {
      CEGUI::WindowManager::getSingleton().getWindow("LoadingDialog")->destroy();
   }
   else
      OGRE_EXCEPT(Exception::ERR_ITEM_NOT_FOUND,"No LoadingDialog exist to be destroyed", "LoadingBar::finish");

   // Unregister listener
   ResourceGroupManager::getSingleton().removeResourceGroupListener(this);

}


I can't see anything get deleted except for the "LoadingDialog".

[dmail]

Maybe you should look at RAII.

[girl]

Hi westpointer, can you post your LoadingBar::start() function?