How to handle dynamic memory allocation failure

thisisbhaskar

yes you can always use standard C++ exception handling if you want.. otherwise, let it just crash.

giesbert

Afaik, most modern compilers use the exception way for out of memory. If you don't like that you have to use the “new (std::nothrow)” notation.
But handling std::out_of_memory is a bit difficult, because, what do you want to do then? Show a dialog? That also allocates memory. Write a log file? same issue....

Meraj Ahmad Ansari

@Gerolf: If memory allocation failed then i want to gracefully shutdown my app.

Meraj Ahmad Ansari

I think its time to reformulate question- I have some code, guys are initializing pointers by NULL, allocating memory and then they are checking that memory allocation failed or not by comparing pointer with NULL.
Please check following code -
@
CSomeClass* p = NULL;
p = new CSomeClass;
if ( NULL != p ) // Is this check relevent???
{
// do something
}
@

i think above check does not have any relevence.
There app is not crashing(by good luck). During code review i found this check useless and their claim is that their memory allocation code is OK.

So I just want to clarify my doubt as i think we can not assume something during development.

koahnig

To my understanding it is common practice to the pointer for proper assignment.
One reason could be that new does not stop the application and simply returns a Null pointer. This is certainly possible if someone writes his/her own new operator.

[quote author="Gerolf" date="1307442082"]
But handling std::out_of_memory is a bit difficult, because, what do you want to do then? Show a dialog? That also allocates memory. Write a log file? same issue....[/quote]

I guess std::out_of_memory means usual cases. If you just try allocate a couple of bytes, you are certainly right. However, if by any wrong input the size to be allocated is outside of your standard sizes, you have and may be you want to have the chance to react on the failure.

koahnig

Here is also some reference showing that not only exotic compilers may return a Null.
http://msdn.microsoft.com/en-us/library/kftdy56f(v=vs.71).aspx

So I guess it is still good practice to check the return value

giesbert

The point is, it is possible to use no throw new, but by default, MSVS uses throwing new

bq. Beginning in Visual C++ .NET 2002, the CRT's new function (in libc.lib, libcd.lib, libcmt.lib, libcmtd.lib, msvcrt.lib, and msvcrtd.lib) will continue to return NULL if memory allocation fails. However, the new function in the Standard C++ Library (in libcp.lib, libcpd.lib, libcpmt.lib, libcpmtd.lib, msvcprt.lib, and msvcprtd.lib) will support the behavior specified in the C++ standard, which is to throw a std::bad_alloc exception if the memory allocation fails.

koahnig

Yes, I understand, but a little further down you will find also:

(4th paragraph) "Even if you use one of the C++ standard library headers, it is possible to get non-throwing new. For example, compile the program below with the following command line and you will not get throwing new behavior, even though standard C++ header files are included: "

So either you restrict the user not to use /EHsc switch or you should be prepared.

PS: I am wondering why the "quote" button does not work anymore :-(

Meraj Ahmad Ansari

Only point is it -if you are using new( no std::nothrow functionality) and after allocation checking its return value to NULL. Is it valid ?
If we are not using std::nothrow then it will not return NULL and subsequent call will crash. But if we are using std::nothrow and checking NULL then developer can take preventive actions(eg. gracefully shutdown).

koahnig

To my understanding, yes.
With checking the pointer for its return value you are more on the save side. You are independent of the actual default setting of your compiler. Also in case someone is changing some switches as possible with the ms compiler, you should be save. However, in case of new with throwing option, you might want to add the functionality catching the out of memory event. This allows you in such cases a graceful shutdown.

Ultimatively, one needs to decide to wear your pants with a belt, with suspenders or with both. ;-)

lgeyer

[quote author="Gerolf" date="1307442082"]But handling std::out_of_memory is a bit difficult, because, what do you want to do then? Show a dialog? That also allocates memory. Write a log file? same issue....[/quote]

There is one thing you can actually do in applications that absolutely have to shutdown gracefully - request a block of memory at startup which serves as an "emergency heap" in case you run out of memory during runtime and use "placement new":http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10 or - if you need support for creating Qt objects too - "custom global allocators":http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.14.

Thus you can still create objects on the heap including a nifty QMessageBox if you want to.

giesbert

[quote author="Meraj Ahmad Ansari" date="1307516970"]Only point is it -if you are using new( no std::nothrow functionality) and after allocation checking its return value to NULL. Is it valid ?
If we are not using std::nothrow then it will not return NULL and subsequent call will crash. But if we are using std::nothrow and checking NULL then developer can take preventive actions(eg. gracefully shutdown).[/quote]

It is not possible that new returns something else than 0 if it can't allocate memory.

return 0

throw exception (nothing is returned, variable is not changed)

If it is throwing, you will not continue as usual, as you have to catch the exception.

andre

[quote author="Lukas Geyer" date="1307521825"][quote author="Gerolf" date="1307442082"]But handling std::out_of_memory is a bit difficult, because, what do you want to do then? Show a dialog? That also allocates memory. Write a log file? same issue....[/quote]

There is one thing you can actually do in applications that absolutely have to shutdown gracefully - request a block of memory at startup which serves as an "emergency heap" in case you run out of memory during runtime and use "placement new":http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10 or - if you need support for creating Qt objects too - "custom global allocators":http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.14.

Thus you can still create objects on the heap including a nifty QMessageBox if you want to.[/quote]

Very interesting idea, but are you sure it would work? I mean: new-ing a messagebox will not just create that message box, but the message box in turn will new other (child) objects. You have no control over how that happens; there is no way you can use placement new or something like that for it, I think? You may be able to write a message into a logfile manually or something like that, but I doubt you could do much more than that. Still, the solution is certainly interesting!

Meraj Ahmad Ansari

bq. @koahnig; ....Also in case someone is changing some switches as possible with the ms compiler,.....

I only want to discuss it under gcc (QtCreator). Does QtCreator support switches? No doubt Visual Studio is really great

bq. @Gerolf : If it is throwing, you will not continue as usual, as you have to catch the exception.

currently my code base is very large and unfortunately with out exception handling and that is why i am thinking about std::nothrow

Thanks to all guys for your support.

koahnig

[quote author="Meraj Ahmad Ansari" date="1307529893"]bq. @koahnig; ....Also in case someone is changing some switches as possible with the ms compiler,.....

I only want to discuss it under gcc (QtCreator). Does QtCreator support switches? No doubt Visual Studio is really great
[/quote]
I am not an expert on QtCreator, but almost everything can be changed on the project's tap. Unfortunately, you have to dig sometimes into the details of a couple of tools.

lgeyer

[quote author="Andre" date="1307523827"]
[quote author="Lukas Geyer" date="1307521825"]
There is one thing you can actually do in applications that absolutely have to shutdown gracefully - request a block of memory at startup which serves as an "emergency heap" in case you run out of memory during runtime and use "placement new":http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10 or - if you need support for creating Qt objects too - "custom global allocators":http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.14.

Thus you can still create objects on the heap including a nifty QMessageBox if you want to.[/quote]

Very interesting idea, but are you sure it would work? I mean: new-ing a messagebox will not just create that message box, but the message box in turn will new other (child) objects. You have no control over how that happens; there is no way you can use placement new or something like that for it, I think? You may be able to write a message into a logfile manually or something like that, but I doubt you could do much more than that. Still, the solution is certainly interesting!

[/quote]

I initially came up with three solutions:

Reserve a bunch of memory at startup and release it when neccessary to gain memory

Reserve a bunch of memory at startup and use it directly as "heap replacement" using placement new

Reserve a bunch of memory at startup and use it directly as "heap replacement" by overloading the global new operator or setting a new handler using std::set_new_handler

It would not prefer 1. because you cannot guarantee that the operating system will return the memory you just freed back to your application (most likely it won't if free memory is rare).

I prefer 2., which usually works flawlessly, provided that your allocation code does so (keyword memory alignment) ;-)

I personally never used 3., because if you usually run out of memory your system is thrashing anyways long before and the application should shut down as soon as possible (without any user interaction). Nevertheless it should work by replacing the global operator new with your own memory management code which can switch between system memory and "emergency memory".

@
// class.h
#ifndef CLASS_H
#define CLASS_H

class Class
{
public:
Class();
};

#endif // CLASS_H

// class.cpp
#include "class.h"

Class::Class()
{
int* pointer = new int;
}

// main.cpp
#include "class.h"

void* operator new(size_t size)
{
// Implementation goes here
}

void operator delete(void* pointer)
{
// Implementation goes here
}

int main(int argc, char argv[])
{
Class pointer = new Class;

return 0;

}
@

Executing the example above shows that both situations are handled correctly (the custom global new operator is called twice); creating objects outside and inside classes.

Setting a new handler using std::set_new_handler which should be called in case of no-new-memory-situations should do the same trick, as it is allowed to either throw an bad_alloc exception or terminate the application or allocating and returning memory somewhere else, for example at our "emergency heap". I think this is the preferred solution for 3. (when having no global / static objects, where you cannot guarantee that std::set_new_handler has been already executed), as you do not have to mess with the global new operator.

Please keep also in mind, that even if new is returning a valid pointer (not returning null) this does not mean that there is actually memory available for the application. If I remember correctly new on Linux systems always returns a valid pointer, as memory is acquired on access, not on allocation!

So the following snippet will crash even due to proper error handling
@
int* integer = new int;
if(integer != 0)
{
*integer = 42; // crash
}
@

Question is, does the runtime call the function set by std::set_new_handler in this case? Never tried that.

koahnig

[quote author="Lukas Geyer" date="1307537741"]
Please keep also in mind, that even if new is returning a valid pointer (not returning null) this does not mean that there is actually memory available for the application. If I remember correctly new on Linux systems always returns a valid pointer, as memory is acquired on access, not on allocation!

So the following snippet will crash even due to proper error handling
@
int* integer = new int;
if(integer != 0)
{
*integer = 42; // crash
}
@

Question is, does the runtime call the function set by std::set_new_handler in this case? Never tried that.[/quote]

But what sense would the check of the pointer make then?

BTW: Is it just in my browser that the last paragraph after the example is NOT shown in the original post?
I just came across it when quoting the post.

koahnig

[quote author="koahnig" date="1307539373"]
BTW: Is it just in my browser that the last paragraph after the example is NOT shown in the original post?
I just came across it when quoting the post.[/quote]

Forget that part. Suddenly the text was there when I had posted my reply.
@Lukas Was your original post updated?

lgeyer

[quote author="koahnig" date="1307539373"]
But what sense would the check of the pointer make then?
[/quote]

No sense, because the pointer returned by new will never be 0.
Even if you override the operator new the compiler won't let you return 0.

[quote author="koahnig" date="1307539373"]
BTW: Is it just in my browser that the last paragraph after the example is NOT shown in the original post?
[/quote]
[quote author="koahnig" date="1307539373"]
Forget that part. Suddenly the text was there when I had posted my reply.
@Lukas Was your original post updated?
[/quote]

This might be the reason ;-)

giesbert

[quote author="Lukas Geyer" date="1307537741"]
Please keep also in mind, that even if new is returning a valid pointer (not returning null) this does not mean that there is actually memory available for the application. If I remember correctly new on Linux systems always returns a valid pointer, as memory is acquired on access, not on allocation!

So the following snippet will crash even due to proper error handling
@
int* integer = new int;
if(integer != 0)
{
*integer = 42; // crash
}
@
[/quote]

This would mean that Linux is not implementing the C++ standard, I can't beleive that.