Hi, For the OpenSolaris Project Sparks (name service switch/nscd enhancements), we have a test suite (nss2) that includes test cases using gcore/mdb/findleaks to detect memory leaks. It works pretty good except that we saw a lot of ::findleaks output like the following that caused the test cases to fail:
stdout| findleaks: maximum buffers => 442 stdout| findleaks: actual buffers => 181 stdout| findleaks: stdout| findleaks: potential pointers => 166153 stdout| findleaks: dismissals => 125325 (75.4%) stdout| findleaks: misses => 36775 (22.1%) stdout| findleaks: dups => 3873 ( 2.3%) stdout| findleaks: follows => 180 ( 0.1%) stdout| findleaks: stdout| findleaks: peak memory usage => 61 kB stdout| findleaks: elapsed CPU time => 0.0 seconds stdout| findleaks: elapsed wall time => 0.0 seconds stdout| findleaks: stdout| BYTES LEAKED VMEM_SEG CALLER stdout| 8192 1 cdb9c000 MMAP stdout| ------------------------------------------------------------------------ stdout| Total 1 oversized leak, 8192 bytes stdout| stdout| mmap(2) leak: [cdb9c000, cdb9e000), 8192 bytes I remember reading someone's weblog (may be Jonathan Adams') saying that these are due to kernel's work and not really are true leaks. But I could no longer find the weblog or document I read. Is this something we should be concerned with ? If so, how do we go about root-causing it ? Thanks, Michen
