Sign in to follow this  

WinMain violates RAII (when code crashes)

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

For example:

int WinMain(/*blah u kno whut*/)
{
CBlah obj;
obj.Foo();
/*crashes here*/
return 0;
}

the destructor of obj wont get called when code crashes, but in main(), it will. the thing is, Im making windows, not console app so I have to use WinMain. Care to advise me?

Share this post


Link to post
Share on other sites
Subsystem (console or windows) and entry point (main or WinMain) are independent parameters. The default projects in Visual Studio defaults to main for the console subsystem and WinMain for the windows subsystem, but you can change these to whatever combination you want.

In Project Settings, Linker, System, you can change subsystem as you like. In Project Settings, Linker, Advanced you can change the entry point of your application; WinMainCRTStartup for WinMain and mainCRTStartup for main.

Share this post


Link to post
Share on other sites
Note that when code crashes that means that you've invoked undefined behavior somewhere. This in turn means that any C++ guarantees about destruction of objects go completely out the window. Your compiler may have ways to force stack unwinding, such as MSVC's SEH mechanisms, but the behavior of any C++ mechanisms are completely coincidental and may not remain stable across builds or even runs of the program.

Share this post


Link to post
Share on other sites
But weird enough, this doesnt happen if Im using main() as entry point (in console application, of course). In console program, any object defined within main() scope gets its destructor called when app crash. This is useful if I call cleanup code in its destructor, for example.

Share this post


Link to post
Share on other sites
Oddly enough the fact that certain behavior is useful has absolutely nothing to do with whether or not you can depend on that behavior. You are trying to rely on undefined behavior and this can and will bite you in the rear.

Share this post


Link to post
Share on other sites
Wow, SiCrane you really give me the creeps <shiver>. So it's undefined behaviour. Well do you know any trick to avoid memory leaks on program crash? some said that I should use try and catch clause. Ive never used that. What is that?? Can it call specific code when my application crashes??

Share this post


Link to post
Share on other sites
Quote:
Original post by Bow_vernon
Wow, SiCrane you really give me the creeps <shiver>. So it's undefined behaviour. Well do you know any trick to avoid memory leaks on program crash? some said that I should use try and catch clause. Ive never used that. What is that?? Can it call specific code when my application crashes??


Try/Catch are the keywords used to handle exceptions. Exceptions are the driving force behind RAII.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bow_vernon
Well do you know any trick to avoid memory leaks on program crash?
That's kind of an ambulance at the bottom of a cliff don't you think?
Not to mention that anything not freed upon program termination is normally automatically reclaimed by the OS, so this cliff already has a massive air-bag at the bottom.

Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
so this cliff already has a massive air-bag at the bottom.


Or at least a massive waste disposal unit to remove any remains that might have a negative effect on the productivity of other citizens.

Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
Not to mention that anything not freed upon program termination is normally automatically reclaimed by the OS, so this cliff already has a massive air-bag at the bottom.
For this reason, cleanup on termination is a non-issue almost everywhere.

If you have an underlying OS (Win/Mac/Linux, iPhone, etc.) then resources will be automatically reclaimed after a crash*. If you don't have an OS (i.e. an embedded platform), then you typically have to reboot the machine anyway after a crash, so leaked resources will simply cease to exist.

* there are a few resources that can't be reclaimed by the OS, notably Unix/Linux semaphores. However, if you are at the point of using semaphores, you probably know enough to handle errors correctly...

Share this post


Link to post
Share on other sites
Oh thx guys, so it's impossible to get a memory leak in nowadays OS. That means I've been wasting time here. Ok back to coding!! :p anyway, those were fast responses which is why I like gamedev.net for clearing out the anxiety :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Bow_vernon
Oh thx guys, so it's impossible to get a memory leak in nowadays OS.



Not quite!

You can still leak memory and other resources. They will almost always be reclaimed by the OS when your program exits, but if you have something running for a significant period of time, leaks can still be very serious problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by ApochPiQ
Quote:
Original post by Bow_vernon
Oh thx guys, so it's impossible to get a memory leak in nowadays OS.



Not quite!

You can still leak memory and other resources. They will almost always be reclaimed by the OS when your program exits, but if you have something running for a significant period of time, leaks can still be very serious problems.

Or, in other words, use appropriate mechanisms such as smart pointers, CComPtr, etc, standard containers (like std::vector) to ensure that you don't leak memory.

Share this post


Link to post
Share on other sites
@ApochPiq: now I know it's the 'runtime memory leak' that I'm always scared of, not 'app crash memory leak', thx.
@Washu: I already did what you mentioned, except CComPtr, I dunno what's that...oh and thx for those replies anyway :D

Share this post


Link to post
Share on other sites
Quote:
now I know it's the 'runtime memory leak' that I'm always scared of, not 'app crash memory leak', thx.

Not being scared of an 'app crash memory leak' shouldn't get you too cozy about an app crash.
There are only a few cases where an app crash may make sense, otherwise, a sanely built application that is well tested should not crash and burn.

Share this post


Link to post
Share on other sites
Quote:
Original post by arithma
There are only a few cases where an app crash may make sense, otherwise, a sanely built application that is well tested should not crash and burn.
Ideally, a shipping application should never crash. Of course in real life it will, so you want to handle such problems gracefully (not losing progress, restoring to the same point on restart, etc.).

During development, however, (which I assume is what the OP was asking about) crashes are likely to occur, with some regularity. As long as you are able to collect the necessary debugging information, these are pretty harmless. As long as you don't discover a driver bug that hard-locks your machine (I love you, Intel GMA), these are really not worth worrying about.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bow_vernon
Well do you know any trick to avoid memory leaks on program crash?


... Don't crash the program? If it crashes, it crashes, and all bets are off about cleanup. Full stop. That's what it means for a program to crash.

Not every kind of "crash" is represented by an exception that can be caught. Not (necessarily) even with SEH (which is not even remotely portable). If the program crashes, it's because there is a bug in it. The way to make sure your program behaves correctly is to fix the bugs.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Quote:
Original post by Bow_vernon
Well do you know any trick to avoid memory leaks on program crash?


... Don't crash the program? If it crashes, it crashes, and all bets are off about cleanup. Full stop. That's what it means for a program to crash.

Not every kind of "crash" is represented by an exception that can be caught. Not (necessarily) even with SEH (which is not even remotely portable). If the program crashes, it's because there is a bug in it. The way to make sure your program behaves correctly is to fix the bugs.


To be honest (and this is a completely personal appreciation), from a user point of view, I prefer a program telling me that some serious error happened and that I should save all my work and close/restart the program by myself ASAP.

Is there something like "user-friendlyness-engineering" out there? It should...

Share this post


Link to post
Share on other sites
Quote:
Original post by owl
To be honest (and this is a completely personal appreciation), from a user point of view, I prefer a program telling me that some serious error happened and that I should save all my work and close/restart the program by myself ASAP.


That would require the program to still be running. This is possible in the case of a caught exception or other detected error but as Zahlman says, a bug-related crash does not necessarily allow for this possibility.

Of course if an error can be detected, the program should behave gracefully and avoid data-loss. I think we are talking about a different class of error here - ones that are due to a fault in the program and as such cannot be detected at runtime.

These can only be addressed by fixing the fault in the first place.

Share this post


Link to post
Share on other sites
Quote:
Original post by Aardvajk
Quote:
Original post by owl
To be honest (and this is a completely personal appreciation), from a user point of view, I prefer a program telling me that some serious error happened and that I should save all my work and close/restart the program by myself ASAP.


That would require the program to still be running. This is possible in the case of a caught exception or other detected error but as Zahlman says, a bug-related crash does not necessarily allow for this possibility.

Of course if an error can be detected, the program should behave gracefully and avoid data-loss. I think we are talking about a different class of error here - ones that are due to a fault in the program and as such cannot be detected at runtime.

These can only be addressed by fixing the fault in the first place.


I totally agree.

Share this post


Link to post
Share on other sites

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