最近在trace directfb有memory leak的的issue
所以找了一些方法來驗證
1. 真的有memory leak的問題嗎?
2. 如何去找到未被free掉的memory
3. 是library實作的"小問題"還是directfb本身的問題…
後來發現有個valgrind的utility還真好用
且libc也有提供trace的interface
$ cat test1.c
#include
#include
int main()
{
mtrace();
GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);
g_hash_table_unref (hash_table);
return 1;
}
$ gcc test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ export MALLOC_TRACE=0.mtrace.log
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
0x0000000000601970 0x7f0 at 0x3fea834002
0x0000000000602400 0x3f0 at 0x3fea8423e1
0x0000000000602800 0x3f0 at 0x3fea8423e1
Now, when the G_ macros are defined, less memory is reported as leaked.
$ export G_DEBUG=gc-friendly
$ export G_SLICE=always-malloc
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
Simple cases such as:
malloc(20);
GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);
g_hash_table_unref (hash_table);
can be easily caught by adding the -g option when compiling:
$ gcc -g test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x14 at /home/user/devel/linux/glib/test1.c:13 <-------- obviously, your code does not free allocated memory
0x0000000000601480 0x1f8 at 0x3fea834002
0x0000000000601680 0xfc at 0x3fea834002
0x0000000000601790 0x1f8 at 0x3fea834002
But when leaks are related to not using glib properly, such as not calling unref, things are more difficult to diagnose:
GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);
$ gcc -g test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
0x0000000000601970 0x38 at 0x3fea83407b
0x00000000006019b0 0x58 at 0x3fea834002 <----------- Is there an memory allocation error? If yes, where and why?
With valgrind, the diagnostics is much better though (note the --leak-check=full option for valgrind and the -g option for gcc):
$ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full ./test1
--- some lines cut out
==4071== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==4071== malloc/free: in use at exit: 2,484 bytes in 7 blocks.
==4071== malloc/free: 7 allocs, 0 frees, 2,484 bytes allocated.
==4071== For counts of detected errors, rerun with: -v
==4071== searching for pointers to 7 not-freed blocks.
==4071== checked 74,704 bytes.
==4071==
==4071== 144 (56 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 5
==4071== at 0x4A05996: malloc (vg_replace_malloc.c:149)
==4071== by 0x3FEA83407A: g_malloc (in /lib64/libglib-2.0.so.0.1200.13)
==4071== by 0x3FEA820CF2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.1200.13)
==4071== by 0x4005E3: main (test1.c:13) <----------------------------------------------------------- AHA! there's the culprit
--- some lines cut out
And when the leak is fixed (add an unref call to the code above), the valgrind output looks better:
==4105== LEAK SUMMARY:
==4105== definitely lost: 0 bytes in 0 blocks.
==4105== possibly lost: 0 bytes in 0 blocks.
==4105== still reachable: 2,340 bytes in 5 blocks.
==4105== suppressed: 0 bytes in 0 blocks.
#include
#include
int main()
{
mtrace();
GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);
g_hash_table_unref (hash_table);
return 1;
}
$ gcc test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ export MALLOC_TRACE=0.mtrace.log
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
0x0000000000601970 0x7f0 at 0x3fea834002
0x0000000000602400 0x3f0 at 0x3fea8423e1
0x0000000000602800 0x3f0 at 0x3fea8423e1
Now, when the G_ macros are defined, less memory is reported as leaked.
$ export G_DEBUG=gc-friendly
$ export G_SLICE=always-malloc
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
Simple cases such as:
malloc(20);
GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);
g_hash_table_unref (hash_table);
can be easily caught by adding the -g option when compiling:
$ gcc -g test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x14 at /home/user/devel/linux/glib/test1.c:13 <-------- obviously, your code does not free allocated memory
0x0000000000601480 0x1f8 at 0x3fea834002
0x0000000000601680 0xfc at 0x3fea834002
0x0000000000601790 0x1f8 at 0x3fea834002
But when leaks are related to not using glib properly, such as not calling unref, things are more difficult to diagnose:
GHashTable* hash_table;
hash_table=g_hash_table_new(g_str_hash, g_str_equal);
$ gcc -g test1.c -o test1 -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include/ -lglib-2.0
$ ./test1; mtrace ./test1 $MALLOC_TRACE
Memory not freed:
-----------------
Address Size Caller
0x0000000000601460 0x1f8 at 0x3fea834002
0x0000000000601660 0xfc at 0x3fea834002
0x0000000000601770 0x1f8 at 0x3fea834002
0x0000000000601970 0x38 at 0x3fea83407b
0x00000000006019b0 0x58 at 0x3fea834002 <----------- Is there an memory allocation error? If yes, where and why?
With valgrind, the diagnostics is much better though (note the --leak-check=full option for valgrind and the -g option for gcc):
$ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full ./test1
--- some lines cut out
==4071== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==4071== malloc/free: in use at exit: 2,484 bytes in 7 blocks.
==4071== malloc/free: 7 allocs, 0 frees, 2,484 bytes allocated.
==4071== For counts of detected errors, rerun with: -v
==4071== searching for pointers to 7 not-freed blocks.
==4071== checked 74,704 bytes.
==4071==
==4071== 144 (56 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 5
==4071== at 0x4A05996: malloc (vg_replace_malloc.c:149)
==4071== by 0x3FEA83407A: g_malloc (in /lib64/libglib-2.0.so.0.1200.13)
==4071== by 0x3FEA820CF2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.1200.13)
==4071== by 0x4005E3: main (test1.c:13) <----------------------------------------------------------- AHA! there's the culprit
--- some lines cut out
And when the leak is fixed (add an unref call to the code above), the valgrind output looks better:
==4105== LEAK SUMMARY:
==4105== definitely lost: 0 bytes in 0 blocks.
==4105== possibly lost: 0 bytes in 0 blocks.
==4105== still reachable: 2,340 bytes in 5 blocks.
==4105== suppressed: 0 bytes in 0 blocks.
