What are really the real consequences to malloc() calls without free()? can it make a program going to crazy,such as a forever loop?

Question

I have a big problem in my current program. Inside on loop,two functions if I do another function call inside this loop,I get a forever loop! even a printf("bah"); give a forever loop.

This give normal execution.

//size = 10 (example)
while(size > 0) {
  a(); // decrement by 2
  b(); // decrement by 2
}

But

//size = 10 (example)
while(size > 0) {
a(); // decrement by 2
b(); // decrement by 2
putchar(' ');
}

Give a forever loop. The single different is the putchar() call.

It's hard to assume something,but some idea to what is happing?

What a() and b()` functions do basically is:

get two structs from an array,decrement size by 1 and printf() some of its members. Such structures aren't freed(yet) only at program end up.

I posted this part of code to tro to get some idea to what is(posibly) happing. All code from this part of code was get is really big(to be posted here for us read).

EDIT:

Here's a minimal a() and b() implmentation:

void a(void) {
  foo_t* f = top;
  while(f->y == STATE_X) {
  get(&a); get(&b); /* it's equivalent to pop() in a linked list. size is size=size-1 in each get call() */
  printf("%d,%d\n",a->x,ab->x);
  f = f->next;
 }
 top = f;
}

void a(void) {
  foo_t* f = top;
  while(f->y == STATE_Y) {
  get(&a); get(&b); /* it's equivalent to pop() in a linked list. size is size=size-1 in each get call() */
  printf("%d,%d\n",a->x,ab->x);
  f = f->next;
 }
 top = f;
}

get() - is my equivalent to pop() in my context.

top - points to last struct footype processed from stack.

size - count of elements currently on stack.

struct footype is implemeted as linked this too,there's a prev and next that points to previously and next member of it.

Answer 1

If we go purely by what you say about the code that's not showing -- that the memory is allocated, but never freed -- then that memory will remain allocated until the program ends. If you continue to allocate more memory without freeing any, eventually you'll run out...at which point malloc may start failing and returning null pointers. (And of course, attempting to access memory via a null pointer can cause all kinds of wackiness to ensue, if we go by the C standard. The most common result in Linux, though, is a segfault.)

However, absent a ulimit setting, you'll probably use up all the swap space as well, which can cause a huge slowdown toward the end. And of course, using all that memory up in your process, takes it away from other processes. Eventually, one of two things is likely to happen:

• The other processes may start failing to allocate memory...and if they haven't accounted for that, they may break.

• Linux will intentionally hand out imaginary memory -- basically, memory pages backed by neither RAM nor swap space. (The reasons for this are a bit complicated, but make sense in context.) Only when a process tries to actually use that memory does the kernel scrounge up some RAM for it. And if there's no free RAM and no room to swap, the kernel will kill an existing process to reclaim its virtual memory.

  (If it goes that far, there's an algorithm that decides which process to kill. It will generally prefer the process that's the worst offender memorywise -- which, in this case, is probably yours.)

That's about the extent of the damage, though. You'll slow things down quite a bit, and mess with other processes, and possibly get one of them killed (likely yours).

One thing it won't do, at least on its own, is cause loops to continue forever. In order for it to cause that, the program would have to (1) check for failure, and (2) loop forever retrying a failed operation til it succeeded, without changing anything relevant to the operation.

Something else is going on here.