valgrind将所有C操作视为“ malloc”和“ free”吗？

Question

At work I'm writing a rather complex piece of software in C, and I frequently test it using valgrind. The program so far works perfectly with no memory leaks or array-bounds violations, and in the valgrind report, the number of 'frees' matched the number of 'mallocs' - great. The thing that bugs me is that it reports thousands of frees and mallocs. And I know for a fact I'm not doing more than about 50-60. I do know that when my program calls 'fopen', that call is counted by valgrind toward the number of mallocs, and similarly 'fclose' is counted toward the number of 'frees'. But in my case, this still doesn't explain the numbers I'm seeing for how many times memory is being malloced and freed. I've scoured my code carefully looking for the culprit, but I got nothing. I can't post any code here for obvious reasons, but I just want to know, am I missing something? Are there other C operations that valgrind counts toward the number of mallocs and frees?

Here's my valgrind report. As you can see, everything looks good from this perspective.

Memcheck, a memory error detector
Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
Command: ./Codec
Parent PID: 3526

HEAP SUMMARY:
     in use at exit: 0 bytes in 0 blocks
   total heap usage: 2,407 allocs, 2,407 frees, 28,877,748 bytes allocated

 All heap blocks were freed -- no leaks are possible

 For counts of detected and suppressed errors, rerun with: -v
 ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

Answer 1

Well, if you call library functions that perform the malloc and free calls you will be seeing lot many allocations and frees. some of the library functions, system calls that does allocations are strdup, pthread_create, timer_create, etc

Answer 2

Remember that there's many function calls that could allocate memory, strdup, fopen, creating threads, loading shared objects, parsing timezone or locale information (as a time related function could require), 3.d party libraries could allocate memory in a number of ways, and so on.

But, run your program with the valgrind massif tool, http://valgrind.org/docs/manual/ms-manual.html (read those docs)

eg

 valgrind --depth=20  --tool=massif ./Calc

This produces a massif.out.XXX file which shows you various sources of allocations, and the snapshot of the heap, eg as an excerpt:

snapshot=9
#-----------
time=137984
mem_heap_B=640
mem_heap_extra_B=40
mem_stacks_B=0
heap_tree=peak
n2: 640 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
 n1: 352 0x4BFD095A: __fopen_internal (in /usr/lib/libc-2.17.so)
  n1: 352 0x4BFD0A39: fopen@@GLIBC_2.1 (in /usr/lib/libc-2.17.so)
   n0: 352 0x8048784: main (tailq_example.c:63)
 n5: 288 0x8048580: add_block (tailq_example.c:20)
  n0: 72 0x8048748: main (tailq_example.c:60)
  n0: 72 0x804875C: main (tailq_example.c:61)
  n0: 72 0x80487DC: main (tailq_example.c:72)
  n0: 72 0x80487F0: main (tailq_example.c:73)
  n0: 0 in 1 place, below massif's threshold (01.00%)