I have a program that throws a std::bad_alloc exception, even though there is clearly plenty of free memory left on my computer (see attached picture of page file usage history in Task Manager). Prior to program execution, memory usage was about 600 MB, during program execution it went up to ~1.3 GB, at which point a bad_alloc was thrown. I'm wondering, why would my program run out of memory so soon?
p.s. my OS in WinXP SP2
Last edited by HighCommander4; August 7th, 2008 at 08:45 PM.
Old Unix programmers never die, they just mv to /dev/null
How big is the allocation? If a sufficiently large allocation is attempted on a sufficiently fragmented heap, an allocation can fail despite there appearing to be enough free memory. It's not a matter of how much memory is free, but of whether or not there is a contiguous region of free memory large enough for the allocation.
How big is the allocation? If a sufficiently large allocation is attempted on a sufficiently fragmented heap, an allocation can fail despite there appearing to be enough free memory. It's not a matter of how much memory is free, but of whether or not there is a contiguous region of free memory large enough for the allocation.
My situation is quite the opposite. I have a large number of small memory allocations. The objects that I am allocating are only 30-40 bytes in size each, but I have ~13 million of them. So, I don't think that the fragmentation is the problem.
Old Unix programmers never die, they just mv to /dev/null
It does sound like a memory fragmentation problem to me. It occurs because of objects of different size are being created and destroyed. You can write a customize allocator that allocate and deallocate from a specific memory pool to minimize fragmentation.
<edit>
Sorry, I mean it sound like memory fragmentation problem. :P
Last edited by Kheun; August 8th, 2008 at 02:09 AM.
quoted from C++ Coding Standards:
KISS (Keep It Simple Software):
Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
Avoid magic number:
Programming isn't magic, so don't incant it.
you should be aware that the default allocator adds extra bytes of memory for each allocation with new you make (I don't know the exact number, something between 4 and 32 bytes) so, instead of 35 bytes being your average allocation, it is in reality 60 bytes. then 13 million of these is about 7 MB which is consistent with your memory usage of 1.3 GB.
You should consider using a small object allocator. The loki library has one and it is free. You can't use it with
VC++ 6.0, but it works with 2005 etc.
As to your problem. You have probably corrupted memory somewhere. Are you sure you don't have any first chance access violations before the bad_alloc is thrown?
Wakeup in the morning and kick the day in the teeth!! Or something like that.
"i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."
you should be aware that the default allocator adds extra bytes of memory for each allocation with new you make (I don't know the exact number, something between 4 and 32 bytes) so, instead of 35 bytes being your average allocation, it is in reality 60 bytes. then 13 million of these is about 7 MB which is consistent with your memory usage of 1.3 GB.
You should consider using a small object allocator. The loki library has one and it is free. You can't use it with
VC++ 6.0, but it works with 2005 etc.
As to your problem. You have probably corrupted memory somewhere. Are you sure you don't have any first chance access violations before the bad_alloc is thrown?
I'm not sure what you mean by 'first chance access violation'. How do I know if one has occurred before the bad_alloc is thrown?
Old Unix programmers never die, they just mv to /dev/null
sorry, I was not clear. You may get a bad_alloc, not because you have run out of memory, but because you have corrupted the heap. If you are lucky this may show up in the debug window as an access violation somewhere before the bad_alloc is thrown. If you are not lucky , then ...
Wakeup in the morning and kick the day in the teeth!! Or something like that.
"i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."
you should be aware that the default allocator adds extra bytes of memory for each allocation with new you make (I don't know the exact number, something between 4 and 32 bytes) so, instead of 35 bytes being your average allocation, it is in reality 60 bytes. then 13 million of these is about 7 MB which is consistent with your memory usage of 1.3 GB.
You should consider using a small object allocator. The loki library has one and it is free. You can't use it with
VC++ 6.0, but it works with 2005 etc.
As to your problem. You have probably corrupted memory somewhere. Are you sure you don't have any first chance access violations before the bad_alloc is thrown?
I took a look at Loki's small object allocator, but I can't quite figure out how to use it. I was expecting an allocator class like std::allocator that I could use instead of std::allocator in instantiating the vectors and other containers that contain my small objects. However, I see nothing of the sort. The only documentation that I could find is rather vague and technical.
Could someone point me in the right direction? A piece of example code using the small object allocator would be really helpful.
Last edited by HighCommander4; August 19th, 2008 at 08:43 PM.
Old Unix programmers never die, they just mv to /dev/null
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
Reply With Quote
Originally Posted by Hermit
