Valgrinding the single_process_tutorial example, it seems getcwd in context.hpp is called with a NULL buffer and 0 size meaning that space is automagically malloc'd (according to POSIX.1-2001). ==10383== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) ==10383== malloc/free: in use at exit: 64 bytes in 1 blocks. ==10383== malloc/free: 32 allocs, 31 frees, 22,225 bytes allocated. ==10383== For counts of detected errors, rerun with: -v ==10383== searching for pointers to 1 not-freed blocks. ==10383== checked 162,760 bytes. ==10383== ==10383== 64 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==10383== at 0x4A0590B: realloc (vg_replace_malloc.c:306) ==10383== by 0x39848C03FC: getcwd (in /lib64/libc-2.5.so) ==10383== by 0x407894: boost::process::basic_work_directory_contextstd::string::basic_work_directory_context() (context.hpp:85) ==10383== by 0x407A19: boost::process::basic_contextstd::string::basic_context() (context.hpp:142) ==10383== by 0x403730: main (single_process_tutorial.cpp:44) ==10383== ==10383== LEAK SUMMARY: ==10383== definitely lost: 64 bytes in 1 blocks. I think the memory should be free()'d if the returned buf isnt NULL (or create a buffer isntead of passing NULL,0). Chris