Is there a limit on the number of malloc calls ?

This is a discussion on Is there a limit on the number of malloc calls ? within the Windows Programming forums, part of the Platform Specific Boards category; I'm having trouble with dynamic memory allocation. Using VC (toolkit 2003) on XP and programming C (not C++), I'm using ...

Is there a limit on the number of malloc calls ?

I'm having trouble with dynamic memory allocation. Using VC (toolkit 2003) on XP and programming C (not C++), I'm using a lot of malloc/free function calls.

All went fine until today. At a certain point in the program, it crashes on the malloc() function. It doesn't really matter in what function malloc() is called or what specific pointer is being allocated... if I remove the malloc(), the program crashes on the next malloc(). And the same malloc() works fine in a previous call to the function containing the malloc/free functions...

I thought I had reached a memory limit, but when I decrease one of the first mallocs (which is always succesful) from about 500000 Bytes to 50000 bytes, the program still crashes at the same later malloc() (which only claims for about 500 bytes).

So I was wondering if there is a limit on the number of calls to malloc ? And how can this be avoided ?

> but when I decrease one of the first mallocs (which is always succesful) from about 500000 Bytes to 50000 bytes,
Just how much memory are you allocating?
I mean, a few hundred rounds of 5MB a time will soon eat up all the memory in your machine.

Do you get any specific error message when it crashes - like trying to access address 0 perhaps?
Do you check that malloc was successful in all cases?

The most common cause for malloc failures is mis-use of the memory from some previous malloc, most commonly referred to as a buffer overflow. If memory has been corrupted, then malloc is usually the first thing to fail as a result.

The amount of memory I try to allocate throughout the program is large, but not huge - the example of 500Kb only occurs in one place.

But I will check all malloc/free code in the program now, perhaps there is some dirty stuff in it - although I was always coding these things quite clean. It's a huge codebase, so I'll need hours to do this checking...

So far I assume there are no compiler settings that could have caused or that can prevent this problem (?).