Tooltip error between windows

Create issue
Issue #38 on hold
Former user created an issue

Automatic migration. Original reporter: "Van"

<b>Version:</b> 0.4.1 (from CVS as of today) <b>Module:</b> CEGUIWindow.cpp <b>Function:</b> const String& Window::getTooltipText(void) const <b>Line:</b> 3160 <bRendering System:</b> Ogre Dagon

This error usually occurs when a window has been deleted and another window is being created. Doesn't always do it, but I can reproduced 1/2 the time.

Reproducibility: sometimes

Additional information: <b>Error:</b> Unhandled exception at 0x00adab76 (CEGUIBase_d.dll) in Client.exe: 0xC0000005: Access violation reading location 0x00000219.

<b>Instruction</b> (Line 3160) if ( d_inheritsTipText && d_parent && d_tooltipText.empty() )

<b>Call Stack</b> CEGUIBase_d.dll!CEGUI::Window::getTooltipText() Line 3160 + 0x3 C++ CEGUIBase_d.dll!CEGUI::Tooltip::doInactiveState(float elapsed=2.1370001) Line 224 + 0x1a C++ CEGUIBase_d.dll!CEGUI::Tooltip::updateSelf(float elapsed=2.1370001) Line 324 C++ CEGUIBase_d.dll!CEGUI::Window::update(float elapsed=2.1370001) Line 2973 + 0x14 C++ CEGUIBase_d.dll!CEGUI::Window::update(float elapsed=2.1370001) Line 2981 C++ CEGUIBase_d.dll!CEGUI::System::injectTimePulse(float timeElapsed=2.1370001) Line 1101 C++ Client.exe!clsEventManager::frameEnded(const Ogre::FrameEvent & evt={...}) Line 77 + 0x2f C++

Comments (3)

  1. Former user Account Deleted

    Original reporter: lindquist

    I have applied a fix for the case where a Window is destruction while controlling the Tooltip, after this I have no longer been able to reproduce it.

    It was a little hard to debug, so I'll close the ticket and consider it gone unless it shows up again.

  2. Former user Account Deleted

    Original reporter: Van

    <b>Version:</b> 0.5.0 RC1 <b>Module:</b> CEGUIWindow.CPP <b>Line:</b> 1931 <b>Function:</b> Window::getTooltipText() <b>GRE:</b> Ogre Dagon 1.2

    DOH! Same problem again. Seem to be fixed in 0.4.1 but has now crept back in to 0.5.0 RC1..

    Error: NULL (Access violation)

    <b>Call Stack</b>

    CEGUIBase_d.dll!CEGUI::Window::getTooltipText() Line 1931 + 0x3 bytes C++

    CEGUIBase_d.dll!CEGUI::Tooltip::doFadeInState(float elapsed=0.035999998) Line 271 + 0x1a bytes C++ CEGUIBase_d.dll!CEGUI::Tooltip::updateSelf(float elapsed=0.035999998) Line 370 C++ CEGUIBase_d.dll!CEGUI::Window::update(float elapsed=0.035999998) Line 1729 + 0x19 bytes C++ CEGUIBase_d.dll!CEGUI::Window::update(float elapsed=0.035999998) Line 1736 + 0x1d bytes C++ CEGUIBase_d.dll!CEGUI::System::injectTimePulse(float timeElapsed=0.035999998) Line 1003 C++ Client.exe!clsInputManager::ProcessListenerEvent(double LoopTime=0.035999999999999997) Line 156 + 0x21 bytes C++ Client.exe!clsEventManager::ProcessEventQueue(clsEventManager::tEventItem * Queue=0x0c9a3748) Line 106 + 0x1e bytes C++ Client.exe!clsEventManager::frameStarted(const Ogre::FrameEvent & evt={...}) Line 64 C++ OgreMain_d.dll!Ogre::Root::_fireFrameStarted(Ogre::FrameEvent & evt={...}) Line 614 + 0x28 bytes C++ OgreMain_d.dll!Ogre::Root::_fireFrameStarted() Line 659 C++ OgreMain_d.dll!Ogre::Root::renderOneFrame() Line 734 + 0x8 bytes C++ OgreMain_d.dll!Ogre::Root::startRendering() Line 727 + 0x8 bytes C++ Client.exe!clsApplication::Main(char * szOptions=0x0012fbd0) Line 186 + 0x11 bytes C++ Client.exe!WinMain(HINSTANCE * hInstance=0x00400000, HINSTANCE * hPrevInstance=0x00000000, char * lpCmdLine=0x002220a2, int nCmdShow=1) Line 24 + 0x12 bytes C++ Client.exe!tmainCRTStartup() Line 578 + 0x35 bytes C Client.exe!WinMainCRTStartup() Line 403 C kernel32.dll!7d4e6e1a() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

  3. Former user Account Deleted

    Original reporter: mrbolha

    I have scrutinized the code, and I believe this happens because, when being destroyed, the window which is the target of the tooltip does not "clean up" by setting the tooltip target back to NULL. The random nature of this bug would be due to the random nature of released heap memory. In order to increase reproducibility for debugging purposes, one could fill the released memory block with zeroes, or some other crash friendly value.

  4. Log in to comment