Debugging strategy to find the cause of bad_alloc

Posted by SalamiArmi on Stack Overflow See other posts from Stack Overflow or by SalamiArmi
Published on 2010-03-20T04:34:52Z Indexed on 2010/03/20 4:41 UTC
Read the original article Hit count: 413

Filed under:
|
|

I have a fairly serious bug in my program - occasional calls to new() throw a bad_alloc.

From the documentation I can find on bad_alloc, it seems to be thrown for these reasons:

  1. When the computer runs out of memory (which definitely isn't happening, I have 4GB of RAM, program throws bad_alloc when using less than 5MB (checked in taskmanager) with nothing serious running in the background).

  2. If the memory becomes too fragmented to allocate new blocks (which, again, is unlikely - the largest sized block I ever allocate would be about 1KB, and that doesn't get done more than 100 times before the crash occurs).

Based on these descriptions, I don't really have anywhere in which a bad_alloc could be thrown.

However, the application I am running runs more than one thread, which could possibly be contributing to the problem. By testing all of the objects on a single thread, everything seems to be working smoothly. The only other thing that I can think of that is going on here could be some kind of race-condition caused by calling new() in more than one place at the same time, but I've tried adding mutexes to prevent that behaviour to no effect.

Because the program is several hundred lines and I have no idea where the problem actually lies, I'm not sure of what, if any, code snippets to post. Instead, I was wondering if there were any tools that will help me test for this kind of thing, or if there are any general strategies that can help me with this problem.

I'm using Microsoft Visual Studio 2008, with Poco for threading.

© Stack Overflow or respective owner

Related posts about c++

Related posts about debugging