Thread: bad_alloc in these situations?

Hello everyone,


In these situations, whether bad_alloc will be thrown?

1. Memory is reserved, even if not used. No "enough" memory to new operator (which reflects not enough memory for VirtualAlloc, even if not used (committed), but reserved);

2. The heap's internal data structures could be corrupted such that it cannot find the next free block (no pointer to the next free block), which would make it think it is out of memory.

3. The heap's internal data structures could be corrupted so that it points to random memory location, which could cause a crash, or try to give you memory that was still in use.

My option, (1) and (2) will throw bad_alloc, for (3) structured exception (access violation) will be thrown?


thanks in advance,
George

Well .... VirtualAlloc() and structured exceptions are both windows specific constructs. But, apart from that ...

If operator new cannot allocate memory it is asked for, it should throw bad_alloc, regardless of whether it uses VirtualAlloc() or not.

Similarly, if operator new fails to find a "free block" (presumably it looks in memory that has previously been returned from the operating system by a function like VirtualAlloc()). I would suggest that, if operator new fails to find a "free block" that it fall back on attempting to obtain more memory (in that case, see previous point).

As to detecting corruption of data structures, that is up to the implementation (i.e. compiler and library). Any corruption of data structures is probably caused by undefined behaviour of some form. By definition, there is no obligation on the implementation to detect such corruption, and no obligation to behave in any particular way if it does. I would suggest that, if it is actually possible to detect data corruption, a practical approach is simply to terminate the program. In practice, however, detection of data corruption can be excessively expensive or (even) impossible.

Thanks Mats and grumpy,

Originally Posted by matsp

Case 1 would throw an exception (although I doubt that new is calling VirtualAlloc in any direct way, it's most likely calling HeapAlloc). VirtualAlloc and HeapAlloc will not throw exceptions of any kind in normal operation (including running out of memory). Obviously some component in the system (e.g. a bad driver that overwrites memory not belonging to the driver) could cause ANYTHING to go wrong, but that applies to ALL system functions...

Case 2, yes, when the allocation function decides that "there is no more memory", then it will throw bad_alloc, whether that is caused by some inconsistent state in the heap or a genuine out of memory situation.

Case 3, if on the other hand it fails to operate correctly because it tries to access invalid memory, it will cause a processor exception, which will turn into a structured exception.

--
Mats

It is good to know out of memory is not the only situation when bad_alloc will be thrown, and other situations like heap data structure corrupted, memory reserved, etc.

Agree with my above conclusion?


regards,
George

Thanks Mats,

Originally Posted by matsp

Just to be clearl, bad_alloc happens when the low-level allocator function "believes" it is out of memory. This is under normal circumstances the same as IT IS out of memory. Anything else is "broken".

It is not normal for the heap to be corrupted, and this situation is definitely undefined behaviour. It is highly likely that a corrupted heap causes a invalid page-fault, which may turn into a structured exception. It is much less likely that the allocation is believed to be correct and that the heap appears empty when it's not.

And VirtualAlloc is not part of new in normal code. So ignore all of that.

What I'm trying to say is that "bad_alloc" is thrown when you are out of memory.

It is like the red light on the dashboard of the car that says "Engine too hot". In 99.9% of the cases, it really means that the engine temp is too high. In special cases, it means that the sensor has broken, and shows too hot for that reason - but that's not what you should expect when the light comes on. Same with bad_alloc - it means that memory couldn't be allocated - 99.9% of the time, that's because there isn't enough memory to allocate in your current process [which is different from the SYSTEM being out of memory - you can have a machine with 64GB of RAM, but a 32-bit process can still only use some 2, 3 or 4GB of that memory].

--
Mats

Question answered.


regards,
George