unlambda in C

unlambdaの実装をCで書いているのだが、sをちゃんとつかうプログラムでは、objectの寿命がかなりわかりにくい。ので。GCでもすんべ、と思った。よって、valgrind投入でございます。

最強のメモリーデバッガーvalgrindの使い方を参考にしてみた。

作業補助のやる気ないMakefile

unlambda: unlambda.c
  gcc -Wall -g -o unlambda unlambda.c

test: unlambda
  valgrind -v --error-limit=no --leak-check=yes --show-reachable=no ./unlambda 2>&1 | tee valgrind.log

DeleteObjectを削除してmakeして得た結果。ばっちり検出してくれている。

==16830== Memcheck, a memory error detector
==16830== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==16830== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==16830== Command: ./unlambda
==16830==
--16830-- Valgrind options:
--16830--    -v
--16830--    --error-limit=no
--16830--    --leak-check=yes
--16830--    --show-reachable=no
--16830-- Contents of /proc/version:
--16830--   Linux version 2.6.32-220.4.2.el6.x86_64 (mockbuild@sl6.fnal.gov) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Mon Feb 13 17:24:24 CST 2012
--16830-- Arch and hwcaps: AMD64, amd64-sse3-cx16
--16830-- Page sizes: currently 4096, max supported 4096
--16830-- Valgrind library directory: /usr/lib64/valgrind
--16830-- Reading syms from /home/nori/Desktop/study/c/unlambda/unlambda (0x400000)
--16830-- Reading syms from /usr/lib64/valgrind/memcheck-amd64-linux (0x38000000)
--16830--    object doesn't have a dynamic symbol table
--16830-- Reading syms from /lib64/ld-2.12.so (0x3135a00000)
--16830-- Reading suppressions file: /usr/lib64/valgrind/default.supp
--16830-- REDIR: 0x3135a17460 (strlen) redirected to 0x38042ae7 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--16830-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so (0x4801000)
--16830-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so (0x4a02000)
==16830== WARNING: new redirection conflicts with existing -- ignoring it
--16830--     new: 0x3135a17460 (strlen              ) R-> 0x04a07830 strlen
--16830-- REDIR: 0x3135a172d0 (index) redirected to 0x4a07470 (index)
--16830-- REDIR: 0x3135a17350 (strcmp) redirected to 0x4a07df0 (strcmp)
--16830-- Reading syms from /lib64/libc-2.12.so (0x3135e00000)
--16830-- REDIR: 0x3135e83980 (strcasecmp) redirected to 0x4801560 (_vgnU_ifunc_wrapper)
--16830-- REDIR: 0x3135e85c40 (strncasecmp) redirected to 0x4801560 (_vgnU_ifunc_wrapper)
--16830-- REDIR: 0x3135e818f0 (__GI_strrchr) redirected to 0x4a072f0 (__GI_strrchr)
--16830-- REDIR: 0x3135e79760 (malloc) redirected to 0x4a05f10 (malloc)
Hello world
--16830-- REDIR: 0x3135e7a590 (free) redirected to 0x4a05890 (free)
==16830== 
==16830== HEAP SUMMARY:
==16830==     in use at exit: 1,000 bytes in 25 blocks
==16830==   total heap usage: 25 allocs, 0 frees, 1,000 bytes allocated
==16830== 
==16830== Searching for pointers to 25 not-freed blocks
==16830== Checked 65,664 bytes
==16830== 
==16830== 960 (440 direct, 520 indirect) bytes in 11 blocks are definitely lost in loss record 4 of 4
==16830==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==16830==    by 0x40058F: NewObject (unlambda.c:33)
==16830==    by 0x400701: print (unlambda.c:103)
==16830==    by 0x40098F: eval (unlambda.c:213)
==16830==    by 0x400A2D: main (unlambda.c:247)
==16830== 
==16830== LEAK SUMMARY: 
==16830==    definitely lost: 440 bytes in 11 blocks
==16830==    indirectly lost: 520 bytes in 13 blocks
==16830==      possibly lost: 0 bytes in 0 blocks
==16830==    still reachable: 40 bytes in 1 blocks
==16830==         suppressed: 0 bytes in 0 blocks
==16830== Reachable blocks (those to which a pointer was found) are not shown.
==16830== To see them, rerun with: --leak-check=full --show-reachable=yes
==16830==    
==16830== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
--16830--   
--16830-- used_suppression:      6 dl-hack3-cond-1
==16830== 
==16830== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)