destroyImageSet causes crash :(

[pjcast]

Well the title says it all, I am trying to destroy an image set so that I can create another one with the same name... However, calling ImagesetManager::getSingleton().destroyImageSet kills the program. The CEGUI log says that the imageset was successfully deleted on the last line with nothing else.
Funny thing is, destroyImageSet works fine as long as the imageset doesn't exist.

Anyway, so I tried to be clever and work around it, I just append a random number at the end of "MyImagesNum" + random
And create a new imageset instead of deleteing the old one...

However, if I create just one imageset, my app works fine and I can exit fine. If I create an additionaly one (1+) image sets, than the app stalls on exiting. Kinda hard to step through since I havn't got my debug setup yet (stlport and VC6 and all). Just wondering if anyone has any ideas?

Though, looks like some sort of buffer overflow: (Image set name is MyImageSet Num#, not ******* or nt

snippet of log during imageset creation:

Code: Select all

8/2004 05:24:25 (InfL2)   Imageset '*******************5555' has been created with texture only.
28/08/2004 05:24:27 (InfL2)   Window 'Demo7/Window3/Image1' has been destroyed.
28/08/2004 05:24:27 (InfL2)   Window 'Demo7/Window3/Image1' of type 'Taharez StaticImage' has been created.
28/08/2004 05:24:27 (InfL2)   Imageset 'ht' has been created with texture only.


It might be on my end, but I don't see how. Or it could be related to the fact that I use the same material, and just recreate a texture each time... Although, the movies/textures do indeed switch/work.

[pjcast]

Ok, I revamped my code a little, decided to get rid of the random image name hack, and have gone back to trying to delete an imageset...

Perhaps my code could help someone spot the problem... and like I mentioned, it works the first time through, but fails on subsequent calls at destroyImageset.

Code: Select all

void CEGUIOgre_TestDriver1::handlePlayButton(const CEGUI::EventArgs& e)
{
   using namespace CEGUI;
   
   FrameWindow* fwnd3 = (FrameWindow*)WindowManager::getSingleton().getWindow((utf8*)"Demo7/Window3");

   Listbox* lbox = (Listbox*)WindowManager::getSingleton().getWindow((utf8*)"Demo7/Window2/Listbox");

   StaticImage* simg = 0;

   try
   {
      CEGUI::String te = mMovieControl->getTextureName();
      
      fwnd3->removeChildWindow( (utf8*)"Demo7/Window3/Image1" );

      simg = (StaticImage*)WindowManager::getSingleton().getWindow((utf8*)"Demo7/Window3/Image1");

      WindowManager::getSingleton().destroyWindow( simg );

      Imageset *tempimg = ImagesetManager::getSingleton().getImageset(
         (utf8*)"MyImagesNumber" );
      
      tempimg->undefineImage( te );
      ImagesetManager::getSingleton().destroyImageset( (utf8*)"MyImagesNumber" );

   }
   catch(...)
   {
      //Tis ok, first time through, set does not exist yet
   }

   const ListboxItem* item = lbox->getFirstSelectedItem();
   Ogre::String str = item->getText().c_str();
   mMovieControl->playMovie( str );

   simg = (StaticImage*)WindowManager::getSingleton().createWindow((utf8*)"Taharez StaticImage", (utf8*)"Demo7/Window3/Image1");
   
   fwnd3->addChildWindow(simg);
   simg->setMaximumSize(Size(1.0f, 1.0f));
   simg->setPosition(Point(0.0f, 0.0f));
   simg->setSize(Size(1.0f, 1.0f));
   simg->setFrameEnabled(false);
   simg->setBackgroundEnabled(false);

   //Now attach Texture to
   if( mMovieControl->getTexture() )
   {
      CEGUI::String temp = "MyImagesNumber";
      CEGUI::String tempName = mMovieControl->getTextureName();

      Imageset *img = ImagesetManager::getSingleton().createImageset(
            temp, mMovieControl->getTexture() );

      unsigned int width = mMovieControl->getWidth();
      unsigned int height= mMovieControl->getHeight();

      img->defineImage( tempName, Point(0.0f,0.0f), Size( width, height ), Point(0.0f,0.0f));

      simg = (StaticImage*)WindowManager::getSingleton().getWindow((utf8*)"Demo7/Window3/Image1");

      simg->setImage( temp, tempName);
   }
}



[CrazyEddie]

I think this could be related to an issue that Spoke reported a while back; basically there are some problems with shared Ogre textures and CEGui imagesets where an Ogre texture basically gets destroyed twice. However, if I remove the destroy call and just keep the unload call, there ends up being memory leaks

For your code, you may benefit from some new bits I'm adding to the Ogre renderer/texture module that allows you create a CEGUI::Texture from an existing Ogre::Texture (and then use that CEGUI::Texture to create your Imageset), when the texture is created in this manner, it is not freed by CEGUI so would not crash.

Ultimately it is a bug, and I hope to fix it when I can come up with a final solution, I'll try and resolve this today, as well as committing the above mentioned new methods.

CE.

[CrazyEddie]

I've added the new texture creation support to CVS and also a half-fix for the bug that always deleted textures (sometimes more than once, sometimes if it disn't own the texture, causing the crashes). Cegui now checks to see if the texture already exists within Ogre and only destroys it later if the texture was actually created for that instance of a CEGUI::Texture (there are still potential pitfalls).

CVS takes 5 hrs to sync for anons. Snapshots are current now. Let me know if this makes any difference to the issue

Thanks,

CE.

[pjcast]

Thanks for the fast posting and fixes, I'll give it a try later and let you know. Perhaps I'll even stop procrastinating and rebuild ogre with debug stlport so I can trace bugs better.

[RuprechtTheMonkeyBoy]

I wonder if this is related to the problem I'm seeing on OS X.

I've gotten CEGUI all the way to completely loading the scheme, but right near the end, I get a series of errors about "double free() or free() in the middle of a block", the last of which causes my app to crash. When I run it through Xcode's debugger, I see what appears to be two consecutive calls to a String destructor. The second call results in "EXC_BAD_ACCESS" because the memory is already freed.

Here's the error output from the app/OGRE:

Code: Select all

Setting up GUI.
GLTexture: Loading gfx/material/Layout.tga with 1 mipmaps from Image.
*** malloc[2186]: Deallocation of a pointer not malloced: 0x36e4f50; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
GLTexture: Loading gfx/material/ogregui.tga with 1 mipmaps from Image.
*** malloc[2186]: Deallocation of a pointer not malloced: 0x361dc10; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
GLTexture: Loading _cegui_ogre_0 with 1 mipmaps from Image.
GLTexture: Loading _cegui_ogre_1 with 1 mipmaps from Image.
../../../OgreMain/src/OgreMemoryManager.cpp:1087: failed assertion `au != 0'


Here's a partial backtrace, if it's helpful:

Code: Select all

(gdb) bt
#0  0x900429ac in kill ()
#1  0x9009eb1c in abort ()
#2  0x07668ecc in __eprintf () at /Users/pauly/Projects/Libraries and Frameworks/ogrenew/OgreMain/include/OgreCodec.h:65
#3  0x07575b18 in Ogre::MemoryManager::dllocMem(char const*, unsigned, char const*, unsigned, void const*, unsigned) (this=0x78b5ac8, sourceFile=0xa6cd0 "/Library/Frameworks/CEGUIBase.framework/Headers/CEGUIString.h", sourceLine=368, sourceFunc=0xa56f4 "???", deallocationType=7, reportedAddress=0x41e3ec0, processID=0) at ../../../OgreMain/src/OgreMemoryManager.cpp:1087
#4  0x075770f4 in Ogre::MemoryManager::op_del_vc(void*, unsigned) (this=0x78b5ac8, reportedAddress=0x41e3ec0, processID=0) at ../../../OgreMain/src/OgreMemoryManager.cpp:1614
#5  0x000ad7e4 in operator delete[](void*) (reportedAddress=0x41e3ec0) at /Library/Frameworks/Ogre.framework/Headers/OgreMemoryManager.h:365
#6  0x000ad6e4 in CEGUI::String::~String() (this=0xbfffdf70, __in_chrg=2) at /Library/Frameworks/CEGUIBase.framework/Headers/CEGUIString.h:368
#7  0x000ad4b8 in CEGUI::String::~String() (this=0xbfffdf70) at /Library/Frameworks/CEGUIBase.framework/Headers/CEGUIString.h:371
#8  0x00010728 in IronHells::Menu::_setupGUI() (this=0x41c3710) at /Users/pauly/Projects/Games/Iron Hells/src/ironhells/handlers/Menu.cpp:425
#9  0x0000f56c in IronHells::Menu::_setupScene() (this=0x41c3710) at /Users/pauly/Projects/Games/Iron Hells/src/ironhells/handlers/Menu.cpp:198
#10 0x0000e9f8 in IronHells::Menu::init(Ogre::RenderWindow*, Ogre::EventProcessor*) (this=0x41c3710, win=0x41811a0, ev=0x4197a20) at /Users/pauly/Projects/Games/Iron Hells/src/ironhells/handlers/Menu.cpp:68


[CrazyEddie]

I'm not sure if it's related, but thatks for the report Is there anything in CEGUI.log?

I'll check through some stuff later and see if I can come up with a cause...

CE.

[RuprechtTheMonkeyBoy]

I'm not sure if it's related, but thatks for the report Is there anything in CEGUI.log?

I'll check through some stuff later and see if I can come up with a cause...

CE.

Sorry, forgot about that file. Here's the log from the beginning of scheme loading to the crash point. There are some extra messages that I added to the scheme code when I was troubleshooting, plus the logging from the bundle loader (I need to tweak those for the appropriate logging levels).

Hope this helps.

Code: Select all

29/08/2004 14:07:37 (InfL1)   ---- Beginning loading of scheme ----
29/08/2004 14:07:37 (InfL2)   Loaded GUI scheme 'TaharezDemo' from data in file 'demoscheme.xml'.
29/08/2004 14:07:37 (InfL2)   ---- Begining resource loading for GUI scheme 'TaharezDemo' ----
29/08/2004 14:07:37 (InfL1)   Loading imagesets...
29/08/2004 14:07:37 (InfL2)   Imageset 'TaharezImagery' has been created from the information specified in file 'TaharezImageset.xml'.
29/08/2004 14:07:37 (InfL2)   Imageset 'OgreGuiImagery' has been created from the information specified in file 'ogregui.xml'.
29/08/2004 14:07:37 (InfL1)   Loading fonts...
29/08/2004 14:07:37 (InfL2)   Imageset 'Tahoma-14_auto_glyph_images' has been created with texture only.
29/08/2004 14:07:37 (InfL2)   Font 'Tahoma-14' has been created from the information specified in file 'tahoma-14.xml'.
29/08/2004 14:07:37 (InfL2)   Imageset 'Tahoma-8_auto_glyph_images' has been created with texture only.
29/08/2004 14:07:37 (InfL2)   Font 'Tahoma-8' has been created from the information specified in file 'tahoma-8.xml'.
29/08/2004 14:07:37 (InfL1)   Loading factories...
29/08/2004 14:07:37 (InfL1)   ---- Beginning exe bundle loading ----
29/08/2004 14:07:37 (InfL1)   Taharez Look
29/08/2004 14:07:37 (InfL1)   Get reference to base bundle
29/08/2004 14:07:37 (InfL1)   Get reference to main bundle
29/08/2004 14:07:37 (InfL1)   Create name
29/08/2004 14:07:37 (InfL1)   Check if .bundle suffix is on name
29/08/2004 14:07:37 (InfL1)   Create bundle URL
29/08/2004 14:07:37 (InfL1)   Couldn't get bundle from main bundle reference; try base
29/08/2004 14:07:37 (InfL1)   Create bundle from URL
29/08/2004 14:07:37 (InfL1)   Release bundle URL
29/08/2004 14:07:37 (InfL1)   Release name reference
29/08/2004 14:07:37 (InfL1)   Load the bundle executable
29/08/2004 14:07:37 (InfL1)   It worked; return the bundle
29/08/2004 14:07:37 (InfL1)   ---- Getting bundle symbol ----
29/08/2004 14:07:37 (InfL1)   Find function pointer for name
29/08/2004 14:07:37 (InfL1)   registerFactory
29/08/2004 14:07:37 (InfL1)   Release bundle name
29/08/2004 14:07:37 (InfL1)   ---- Done getting bundle symbol ----
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Frame Window' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Titlebar' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Button' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Close Button' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Checkbox' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez RadioButton' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Slider' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Slider Thumb' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez ProgressBar' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez AltProgressBar' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Editbox' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez VertScrollbar' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez VertScrollbarThumb' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez MiniVertScrollbar' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez MiniVertScrollbarThumb' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez MiniHorzScrollbar' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez MiniHorzScrollbarThumb' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez StaticImage' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez StaticText' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Listbox' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez Combobox' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez ComboEditbox' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez ComboDropList' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez ListHeaderSegment' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez ListHeader' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez MultiColumnList' windows added.
29/08/2004 14:07:37 (InfL2)   WindowFactory for 'Taharez MultiLineEditbox' windows added.
29/08/2004 14:07:37 (InfL1)   Loading aliases...
29/08/2004 14:07:37 (InfL2)   ---- Resource loading for GUI scheme 'TaharezDemo' completed ----
29/08/2004 14:07:37 (InfL1)   Got scheme object.
29/08/2004 14:07:37 (InfL1)   TaharezDemo
29/08/2004 14:07:37 (InfL1)   ---- Done loading scheme ----


[CrazyEddie]

Thanks for the log; no trouble reported there

I didn't get a chance to look at anything yet, but I'm about to have a quick look now...

[CrazyEddie]

@RuprechtTheMonkeyBoy:
I didn't find anything amiss in the gui code, so can we see _setupGUI() ?

CE

[RuprechtTheMonkeyBoy]

@RuprechtTheMonkeyBoy:
I didn't find anything amiss in the gui code, so can we see _setupGUI() ?

CE

Certainly. It's pretty much lifted right out of demo 7. From what I can tell, it crashes coming out of loadScheme().

Code: Select all

     bool Menu::_setupGUI(void)
     {
          LogManager::getSingleton().logMessage(
                    "Setting up GUI.",
                    LML_TRIVIAL);
                   
         
          guiRenderer = new CEGUI::OgreRenderer(window,
                    Ogre::RENDER_QUEUE_OVERLAY, false, 5000 /* CEGUI_MAX_QUADS */,
                    sceneMgr);
          if(!guiRenderer)
          {
               LogManager::getSingleton().logMessage(
                         "Unable to create GUI renderer!",
                         LML_CRITICAL);
               return false;
          }
         
          guiSystem = new CEGUI::System(guiRenderer);
          if(!guiSystem)
          {
               LogManager::getSingleton().logMessage(
                         "Unable to create GUI system!",
                         LML_CRITICAL);
               return false;
          }
         
          try
          {
               using namespace CEGUI;
     
               Logger::getSingleton().setLoggingLevel(Insane /* Informative */);

               // Load scheme and set up defaults.
               SchemeManager::getSingleton().loadScheme((utf8*)"demoscheme.xml");
               System::getSingleton().setDefaultMouseCursor((utf8*)"TaharezImagery", (utf8*)"MouseArrow");
               System::getSingleton().setDefaultFont((utf8*)"Tahoma-14");
     
               Window* sheet = WindowManager::getSingleton().createWindow((utf8*)"DefaultGUISheet", (utf8*)"root_wnd");
               System::getSingleton().setGUISheet(sheet);

          }
          // Catch to prevent exit (errors will be logged).
          catch(CEGUI::Exception)
          {
               LogManager::getSingleton().logMessage(
                         "Unable to load GUI elements.",
                         LML_CRITICAL);
          }

          return true;
     }


[CrazyEddie]

Judging from all the diagnostics, the crash is occurring when one of the auto created strings (probably from (utf8*)"demoscheme.xml") is destroyed, though this should not produce this behaviour.

The destructor for String contains two delete[] lines surrounded by conditionals, it appears that somewhere one of these lines are executing incorrectly and attempting to delete an invalid or uinitialised pointer.

I have checked appropriate areas of the string code and nothing is jumping out at me as the cause, so I don't have much in the way of suggestions at the moment other than to suggest stepping through some code to see if you can come up with anything. It may also be worthwhile just creating a few CEGUI::String objects and destroying them trying to pinpoint the exact cause of the problem.

I see in the Ogre log that there's also a memory related anomaly logged after each Imageset is loaded, so in my opinion at the moment it would appear that there's something odd happening within the XML parsing code (although this does not agree with my point in the first paragraph above).

Obviously, I'll keep thinking and if anything comes to mind I'll post again

CE.

[RuprechtTheMonkeyBoy]

Judging from all the diagnostics, the crash is occurring when one of the auto created strings (probably from (utf8*)"demoscheme.xml") is destroyed, though this should not produce this behaviour.

The destructor for String contains two delete[] lines surrounded by conditionals, it appears that somewhere one of these lines are executing incorrectly and attempting to delete an invalid or uinitialised pointer.

I did some poking around myself, and here's what I've found:

1. The stack trace shows on items 6 and 7 that the same string is being destroyed twice (judging by the "this" pointer on both items).
2. The failure happens by an assertion in the Ogre memory manager, namely, that "au" (a local variable in dllocMem) is NULL. A comment in the code right before that assertion states:

Code: Select all

// If you hit this assert, you tried to deallocate RAM that wasn't
// allocated by this memory manager.
m_assert(au != NULL);


So, why is it using the Ogre memory manager, when only the renderer should be pulling in Ogre headers, etc.?

3. I tried amending the CEGUI::String destructor to explicitly zero out the variables that are being delete[]d, so that perhaps the second time through it wouldn't try to do it again, but it didn't make a difference.

If the CEGUI::String code works on Windows and Linux, but not here, then I have to ask myself if perhaps I didn't build Ogre, or more likely, CEGUI, improperly. Should the CEGUI build be using the Ogre memory manager? (I would think that it shouldn't.)

I'm going to try building again CEGUI again after tweaking the project settings.

It may also be worthwhile just creating a few CEGUI::String objects and destroying them trying to pinpoint the exact cause of the problem.

I tried this, but couldn't get it to fail.

[pjcast]

THe way Ogrememory manager can get pulled in is if there are cases of new or delete within CEGUI header files and they get included after some Ogre headers... As I don't have source on this computer I don't know, just a guess, though new'ing and delete in headers files can be dangerous across DLL boundaries, and in cases where new/delete get changed with different lib's.

[CrazyEddie]

The String class is all inline code in the header, so related to what pjcast says, if the cegui headers appear after the Ogre headers in someplace but not others, you could end up with some strings being allocated "normally" and others going through the Ogre memory manager; though I'm not sure if this is the problem or not (sounds like a possibility though).

To answer a couple of your points

1. Items 6 and 7: I'm not sure why there's two calls in there like that, the backtrace is basically saying that the destructor called the destructir which we can see does not happen, there must be some other explanation for that (what's the __in_chrg=2 in the second one mean?).

2. Yes saw that myself. Looks like it could be caused by what's described in the first paragraph above.

It's very annoying that you've gotten caugt up in a problem like this

CE.