Page 1 of 1
Crash on ProgressBar
Posted: Fri Dec 19, 2008 09:40
by 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.
Posted: Fri Dec 19, 2008 13:21
by 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
Posted: Fri Dec 19, 2008 13:25
by 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.
Posted: Fri Dec 19, 2008 13:35
by CrazyEddie
I give up. Truly, I do.
Posted: Fri Dec 19, 2008 14:04
by 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?

Posted: Fri Dec 19, 2008 14:46
by 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.
Posted: Fri Dec 19, 2008 18:27
by 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

Posted: Sat Dec 20, 2008 01:36
by 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?
Posted: Sat Dec 20, 2008 02:29
by 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)
Posted: Sat Dec 20, 2008 12:00
by 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.
Posted: Sun Dec 21, 2008 01:10
by 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".
Posted: Sun Dec 21, 2008 13:51
by dmail
Maybe you should look at
RAII.
Posted: Wed Feb 04, 2009 13:43
by girl
Hi westpointer, can you post your LoadingBar::start() function?