Sign in to follow this  

Global object's destructor not called when code crashes

This topic is 2542 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

However, if I put the object at main() scope, its destructor gets called even when crashing.

//this works
void main()
{
CBlah obj;
}
//this wont do
CBlah obj;
void main()
{
}

I need the destructor to be called(evn in a crash)but also to make the object accessible at the global scope..

Share this post


Link to post
Share on other sites
best solution: find a way to not need it to be at global scope. globals are always a last resort.

oh, and don't just pack it into a singleton :) no lipstick-on-a-pig solutions.

just have it in main, and pass it around as needed.

Share this post


Link to post
Share on other sites
But how? Im writing a logger class, which open file handle in constructor and close it in the destructor...it should be accessible at global scope. Oh and I'm avoiding those horrible singletons as you suggest, I dont like it either....

Share this post


Link to post
Share on other sites
Normally when a process is killed, the OS should close all open handles, so I wouldn't worry much about the case when the application crashes. Plus, when the application crashes, you don't really have all that much control about what happens.

You usually see a crash when for example a segmentation fault (or anything else that will trigger a hardware interrupt) is caught by a handler, but unless you dereference a null pointer, you really don't know what has happened before that. Your application might have been writing 50 megabytes past the end of an array in an endless loop before eventually hitting a page that isn't writable. Which means, any data in your logger class including the handle value could already have been overwritten with rubbish, and you don't know. There's simply no way you can protect yourself against what happens in a crash.

In case of C++ exceptions, everything will be smooth anyway, it's just the hard crashes that will bug you, and like I said, not much you can do there really. Even installing a vectored exception handler won't be 100% safe since you cannot know what happened before your handler is called.

Share this post


Link to post
Share on other sites
@japro: Thx man, I've already done that and it worked nicely. Im happy with that!
@samoth: Well I know that, It's just Im trying to write a memory manager also, not just a logger class.
OK now everything's smooth and nice, and Im sure there will be no more memory leak....

Share this post


Link to post
Share on other sites
my logger normally opened and closed for every single log. so all i did was log("bla") and be done with it. worked very well, and allowed to open the log while the app was running (opened in the browser and f5ed all the way to see the actual state).

so no need for the global.

otherwise, you could have it in the logger class / namespace to be at least not in the public domain per se.

Share this post


Link to post
Share on other sites
@Dave: Well it's not a problem, anyway Im logging specific engine log at the logger constructor and destructor. By making sure the logger's destructor called, I dont have to log those specific info (it's automatically called)... and Im writing a memory manager too. what starts should finishes, rite?

Share this post


Link to post
Share on other sites
just make sure the logfile actually has data in, even if the log destructor isn't called. that can often be a problem, then.

for your other points, yes of course. that's why i love RAII.

have fun doing the lowlevel stuff. i remember it from long time ago :)

Share this post


Link to post
Share on other sites
When the code crashes, you can't rely on *anything* happening.

A crash could be a hardware failure. It could bluescreen the OS; it could lock the system solid. So even files which were written before the crash, aren't safe unless you fsync()'d them and got back a positive result (This assumes the machine has non-lying hardware)

A really robust application should be able to recover from any kind of shutdown, including an OS / hardware failure; this means that a program crash is relatively "clean".

If you read up on the principle "crash-only", you'll realise, that doing anything in your global destructor is essentially futile (or at best, unnecessary).

A crash-only program should not rely on a global destructor being executed, or indeed any other destructor, if the program stops executing.

"Stops executing" here, meaning that it's not running any more, as a result of a normal quit operation, program crash, OS crash, hardware failure, intercontintenal thermonuclear war etc.

Share this post


Link to post
Share on other sites

This topic is 2542 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this