Jump to content
  • Advertisement
Sign in to follow this  
Saandman

Memory manager out of scope somehow *SOLVED.. kinda*

This topic is 4845 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've written a very simple but a just what I need memory manager, in C++. Now, it works as it should, or at least did. I changed my application flow and now the memory manager is somehow destroyed before all my allocated objects. I can't figure out HOW this is possible! My app generally looks like this: (main.cpp)
// create application instance
GApplication app(GString("GameApp"));
app.init(instance, &cmd);

// add a task (nothing to do with the problem really)
TestTask *task = new TestTask();
task->setPriority(6.0f);
app.addTask(task);

// run the app (see below)
int ret = app.main();

// application ended - app leaks!
delete task;
return ret;


The application class handles task processing and inits interfaces like graphics, sound, input etc and everything IS deleted in the app destructor. The memory manager is a singleton and overrides calls to new/delete. But since the app instance isn't dynamically allocated, in which order are the instances destroyed? I've tried allocating memory for the app class so I could explicitly delete it before the program ends, but I get the same leaks. It's like the memory manager singleton is prematurely destructed.. Anyone got any pointers? [Edited by - Saandman on August 10, 2005 2:07:42 PM]

Share this post


Link to post
Share on other sites
Advertisement
The construction and destrutction order of global and static objects is undefined with respect to other global/static objects.

Share this post


Link to post
Share on other sites
What Nitage is saying is that global and static objects are not constructed and destructed in any defined order -- therefore, you must treat them as being constructed all at the same instant and destructed all at the same instant, or rather treat each one as being constructed before every other and destructed after every other.

More specifically in this instance, the problem may lie in the destruction of app. App is created in the program's execution area rather than dynamically allocated from the heap, so its destruction is probably taking place later than you want it to.

What you might try in order to fix this is changing over to dynamic memory allocation, from the heap. The surface changes are minimal:

// create application instance
GApplication *app;
app = new GApplication(GString("GameApp"));
app->init(instance, &cmd);

// add a task
TestTask *task = new TestTask();
task->setPriority(6.0f);
app->addTask(task);

// run the app (see below)
int ret = app->main();

// application ended
delete task;
delete app;
return ret;




Share this post


Link to post
Share on other sites
Thanks both of you I eventually solved the app part, but now I'm stuck with quite a few string objects that are never going to get "officially" deallocated because the mem manager "goes out of scope". I'm actually finding this whole deal quite funny.. :)

Share this post


Link to post
Share on other sites
I just ran into a problem just like this. I'd always thought that static class objects were constructed the first time that they were used (like static objects in functions). I didn't notice this for a long time because I created all the dependant objects on the heap. But once I did try to add a managed object to a global variable...BANG. Always fun having to rework a design that *did* work before [wink].

Share this post


Link to post
Share on other sites
Quote:
Original post by Thunder_Hawk
I just ran into a problem just like this. I'd always thought that static class objects were constructed the first time that they were used (like static objects in functions). I didn't notice this for a long time because I created all the dependant objects on the heap. But once I did try to add a managed object to a global variable...BANG. Always fun having to rework a design that *did* work before [wink].


Oh God, I feel the pain.. I had a great design, loads of toiled-over and loved code, only to have it all blow up in my face only because for some god-forsaken reason, it was relying on static-initialization... That was the major reason I had to rewrite 90& of my core code [sick] Or well, that would have left me rewriting about 30%, but I felt it would be smarter to just start from scratch again, and refactor what I could..

Saandman: Sorry I can't add anything in regards to your problem, but your latest issue seems more like a problem with the implementation, rather then undefined behaviour, which requires that people be able to see the code in question.. Anyway, hope you solve it ASAP.

Share this post


Link to post
Share on other sites
Hehe yeah if I had a penny.. Anyway thanks, yeah it's definately an implementation specific problem now, since the result changes depending on where I decide to collect the garbage. I see a solution but I don't wanna :) I guess in the end there's no avoiding re-designing a small part.

Thanks, bye.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!