CEGUI (Crazy Eddie's GUI) Forums

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:


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.

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.

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.

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.

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.

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:



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

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.

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.

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...

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

CE

@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().

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.

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:



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.

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.

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.