If you use valgrind you'll notice that pgrep leaks memory: % valgrind --tool=memcheck --trace-children=yes --leak-check=full pgrep some_process Reproducible: Always Steps to Reproduce: 1. use pgrep to find a process 2. 3. Actual Results: valgrind --tool=memcheck --trace-children=yes --leak-check=full pgrep kdevelop ==16091== Memcheck, a memory error detector. ==16091== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==16091== Using LibVEX rev 1732, a library for dynamic binary translation. ==16091== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==16091== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==16091== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==16091== For more details, rerun with: -v ==16091== 5605 5616 ==16091== ==16091== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==16091== malloc/free: in use at exit: 16,836 bytes in 148 blocks. ==16091== malloc/free: 257 allocs, 109 frees, 22,696 bytes allocated. ==16091== For counts of detected errors, rerun with: -v ==16091== searching for pointers to 148 not-freed blocks. ==16091== checked 137,100 bytes. ==16091== ==16091== 16 bytes in 1 blocks are definitely lost in loss record 1 of 14 ==16091== at 0x402151D: malloc (vg_replace_malloc.c:149) ==16091== by 0x402165C: realloc (vg_replace_malloc.c:306) ==16091== by 0x8049E50: main (pgrep.c:514) ==16091== ==16091== ==16091== 9,820 (32 direct, 9,788 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 14 ==16091== at 0x402151D: malloc (vg_replace_malloc.c:149) ==16091== by 0x8049812: main (pgrep.c:391) ==16091== ==16091== ==16091== 7,000 bytes in 86 blocks are definitely lost in loss record 13 of 14 ==16091== at 0x40215ED: realloc (vg_replace_malloc.c:306) ==16091== by 0x403E68A: xrealloc (alloc.c:42) ==16091== by 0x40412C2: file2strvec (readproc.c:465) ==16091== by 0x40425F8: simple_readproc (readproc.c:593) ==16091== by 0x4041661: readproc (readproc.c:786) ==16091== by 0x80498D0: main (pgrep.c:435) ==16091== ==16091== LEAK SUMMARY: ==16091== definitely lost: 7,048 bytes in 88 blocks. ==16091== indirectly lost: 9,788 bytes in 60 blocks. ==16091== possibly lost: 0 bytes in 0 blocks. ==16091== still reachable: 0 bytes in 0 blocks. ==16091== suppressed: 0 bytes in 0 blocks. Expected Results: valgrind --tool=memcheck --trace-children=yes --leak-check=full ./pgrep kdevelop ==16112== Memcheck, a memory error detector. ==16112== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==16112== Using LibVEX rev 1732, a library for dynamic binary translation. ==16112== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==16112== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==16112== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==16112== For more details, rerun with: -v ==16112== 5605 5616 ==16112== ==16112== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==16112== malloc/free: in use at exit: 0 bytes in 0 blocks. ==16112== malloc/free: 257 allocs, 257 frees, 22,702 bytes allocated. ==16112== For counts of detected errors, rerun with: -v ==16112== All heap blocks were freed -- no leaks are possible. pgrep should clean up memory which was allocated.
Created attachment 134106 [details, diff] Fixes memory leaks of pgrep.
According to http://procps.sourceforge.net/faq.html I sent the patch to <procps-feedback@lists.sf.net>
i dont think it's really a problem ... all memory is freed automatically by the kernel when the process calls exit() i'll leave it up to upstream as to whether they add the patch to the sources
