I believe packet-o-matic revision 368 is leaking some memory every time an input is started. For example, consider the following configuration file: http.cap 80 With http.cap a small pcap capture file that is read in less than a second. We can reproduce the problem like this: $ packet-o-matic -c pom.xml.conf --pid pom.pid -b ; while true; do egrep 'RSS|VmSize' /proc/`cat pom.pid`/status ; echo -ne 'input start\r\n' | nc -q1 localhost 4655 > /dev/null ; done main: Config file is pom.xml.conf main: PID file is pom.pid VmSize: 70024 kB VmRSS: 18060 kB VmSize: 758536 kB VmRSS: 59688 kB VmSize: 766800 kB VmRSS: 62516 kB VmSize: 774996 kB VmRSS: 86072 kB VmSize: 783192 kB VmRSS: 121800 kB VmSize: 856924 kB VmRSS: 157332 kB VmSize: 865120 kB VmRSS: 190116 kB VmSize: 873316 kB VmRSS: 220140 kB VmSize: 881512 kB VmRSS: 247656 kB VmSize: 889708 kB VmRSS: 272572 kB We can clearly see unbounded increase in memory usage. Using Valgrind, we can track this down to the start_input() function: ==3364== ==3364== 1,632 bytes in 6 blocks are possibly lost in loss record 2 of 2 ==3364== at 0x4C203E4: calloc (vg_replace_malloc.c:397) ==3364== by 0x40108BE: _dl_allocate_tls (in /lib/ld-2.7.so) ==3364== by 0x67BC6BA: pthread_create@@GLIBC_2.2.5 (in /lib/libpthread-2.7.so) ==3364== by 0x406948: start_input (main.c:348) ==3364== by 0x411988: mgmtcmd_input_start (mgmtcmd_input.c:168) ==3364== by 0x40CBB1: mgmtsrv_process_command (mgmtsrv.c:432) ==3364== by 0x40E231: mgmtvty_process_key (mgmtvty.c:739) ==3364== by 0x40E7BC: mgmtvty_process (mgmtvty.c:260) ==3364== by 0x40CD3C: mgmtsrv_read_socket (mgmtsrv.c:294) ==3364== by 0x40D0DF: mgmtsrv_process (mgmtsrv.c:204) ==3364== by 0x406A66: mgmtsrv_thread_func (main.c:285) ==3364== by 0x67BCFC6: start_thread (in /lib/libpthread-2.7.so) The relevant code looks like this: 77 static pthread_t input_thread; ... 311 int start_input(struct ringbuffer *r) { ... 348 if (pthread_create(&input_thread, NULL, input_thread_func, (void*)r)) { And the corresponding pthread_join() is supposed to be performed in stop_input(): 365 int stop_input(struct ringbuffer *r) { ... 388 pthread_join(input_thread, NULL); However, stop_input() is only called in two cases: - on process termination; - when explicitely requested from the user. Consequently, the thread memory resources are never deallocated when the input thread completes "naturally" when input_thread_func() returns by itself after the input file has been fully processed. Here is a possible fix: Index: src/main.c =================================================================== --- src/main.c (revision 368) +++ src/main.c (working copy) @@ -525,6 +525,8 @@ void *input_thread_func(void *params) { pom_log(POM_LOG_DEBUG "Input thread stopped"); + pthread_detach(input_thread); + return NULL; } Instead of trying to figure out a good place to do the pthread_join(), we just pthread_detach() immediately before returning thus automatically releasing the pthread ressources without disturbing any other thread that would already be pthread_join()ing on us. With this patch, Valgrind stops complaining. I also measured the actual change in memory usage with a small shell script and plotted the result. Details are available from http://fruli.krunch.be/~krunch/src/pom/ The file pomleak.png clearly shows that without the patch the VM size keeps growing for each iteration. Interestingly the RSS seems to grow faster with the patch than without (but the difference is much less dramatic). This might be indicative of another leak that is not made obvious by Valgrind.