CODEWITHSUNDEEP
cvalgrind
Villemoes
Villemoes

Reputation: 215

valgrind/memcheck fails to release "large" memory chunks

Consider this small program:

#include <stdio.h>
#include <stdlib.h>

// Change 60000 to 70000 and valgrind (memcheck) eats my memory
#define L (60000)
#define M (100*(1<<20))

int main(void) {
  int i;
  for (i = 0; i < M; ++i) {
    unsigned char *a = malloc(L);
    a[i % L] = i % 128; // Touch something; a[0] is not enough
    free(a);
    if (i % (1<<16) == 0)
      fprintf(stderr, "i = %d\n", i);
  }
  return 0;
}

Compiling with gcc -o vg and running valgrind --leak-check=full ./vg works fine, with memcheck using roughly 1.5% of my memory. However, changing L to 70000 (I suppose the magic limit is 1<<16), memcheck uses an ever-increasing amount of memory, until the kernel finally kills it.

Is there anything one can do about this? There is obviously no leak, but there appears to be one in valgrind itself (!?), making it difficult to use for checking programs with lots of large and short-lived allocations.

Some background, not sure which is relevant:

$ valgrind --version
valgrind-3.7.0
$ gcc --version
gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
$ /lib/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
$ uname -rms
Linux 2.6.32-220.2.1.el6.x86_64 x86_64

Upvotes: 1

Views: 248

Answers (2)

phd
phd

Reputation: 586

This is very likely caused by a gcc 4.4 bug, which is bypassed in valgrind 3.8.0 (not yet released)

extract from Valgrind 3.8.0 NEWS file:

n-i-bz Bypass gcc4.4/4.5 wrong code generation causing out of memory or asserts

Upvotes: 1

Jay D
Jay D

Reputation: 3297

Set the resource limit of your process to unlimited using setrlimit So that kernel won't kill your process if you exceed men limit. And thus kernel think you are okay extending into the virtual address space.

Hope this helps.

Upvotes: 0

Related Questions