Package: man-db Version: 2.4.3-3 Severity: normal apropos leaks ~100KB for each query.
xterm -e top &while :; do echo adventure; done |xargs apropos I was using apropos to test for which glibc symbols have manpages. For a single query: |==19144== 39 bytes in 1 blocks are possibly lost in loss record 4 of 17 |==19144== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19144== by 0x8051171: xmalloc (xmalloc.c:66) |==19144== by 0x80510A0: xstrdup (xstrdup.c:38) |==19144== by 0x804ADDE: add_sections (manp.c:178) |==19144== by 0x804BB44: add_to_dirlist (manp.c:748) |==19144== by 0x804BBF8: read_config_file (manp.c:789) |==19144== by 0x804CF56: manpath (manp.c:577) |==19144== by 0x804AB21: main (whatis.c:742) | |==19144== 63,775 bytes in 2,891 blocks are definitely lost in loss record 17 of 17 |==19144== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19144== by 0x8051171: xmalloc (xmalloc.c:66) |==19144== by 0x80510A0: xstrdup (xstrdup.c:38) |==19144== by 0x8049AB8: main (whatis.c:639) For a multiple query (of the same name twice): |==19180== 39 bytes in 1 blocks are possibly lost in loss record 6 of 31 |==19180== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19180== by 0x8051171: xmalloc (xmalloc.c:66) |==19180== by 0x80510A0: xstrdup (xstrdup.c:38) |==19180== by 0x804ADDE: add_sections (manp.c:178) |==19180== by 0x804BB44: add_to_dirlist (manp.c:748) |==19180== by 0x804BBF8: read_config_file (manp.c:789) |==19180== by 0x804CF56: manpath (manp.c:577) |==19180== by 0x804AB21: main (whatis.c:742) | |==19180== 256 bytes in 1 blocks are definitely lost in loss record 21 of 31 |==19180== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19180== by 0x40DC632: regcomp (regcomp.c:485) |==19180== by 0x804A954: main (whatis.c:754) | |==19180== 8,452 (164 direct, 8,288 indirect) bytes in 1 blocks are definitely lost in loss record 25 of 31 |==19180== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19180== by 0x401C90C: realloc (vg_replace_malloc.c:306) |==19180== by 0x40DC195: re_compile_internal (regcomp.c:774) |==19180== by 0x40DC6AA: regcomp (regcomp.c:504) |==19180== by 0x804A954: main (whatis.c:754) | |==19180== 127,473 (127,382 direct, 91 indirect) bytes in 5,772 blocks are definitely lost in loss record 31 of 31 |==19180== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19180== by 0x8051171: xmalloc (xmalloc.c:66) |==19180== by 0x80510A0: xstrdup (xstrdup.c:38) |==19180== by 0x8049AB8: main (whatis.c:639) For a multiple query (of two distinct names): |==19196== 39 bytes in 1 blocks are possibly lost in loss record 6 of 31 |==19196== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19196== by 0x8051171: xmalloc (xmalloc.c:66) |==19196== by 0x80510A0: xstrdup (xstrdup.c:38) |==19196== by 0x804ADDE: add_sections (manp.c:178) |==19196== by 0x804BB44: add_to_dirlist (manp.c:748) |==19196== by 0x804BBF8: read_config_file (manp.c:789) |==19196== by 0x804CF56: manpath (manp.c:577) |==19196== by 0x804AB21: main (whatis.c:742) | |==19196== 256 bytes in 1 blocks are definitely lost in loss record 21 of 31 |==19196== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19196== by 0x40DC632: regcomp (regcomp.c:485) |==19196== by 0x804A954: main (whatis.c:754) | |==19196== 8,452 (164 direct, 8,288 indirect) bytes in 1 blocks are definitely lost in loss record 25 of 31 |==19196== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19196== by 0x401C90C: realloc (vg_replace_malloc.c:306) |==19196== by 0x40DC195: re_compile_internal (regcomp.c:774) |==19196== by 0x40DC6AA: regcomp (regcomp.c:504) |==19196== by 0x804A954: main (whatis.c:754) | |==19196== 127,473 (127,389 direct, 84 indirect) bytes in 5,774 blocks are definitely lost in loss record 31 of 31 |==19196== at 0x401B422: malloc (vg_replace_malloc.c:149) |==19196== by 0x8051171: xmalloc (xmalloc.c:66) |==19196== by 0x80510A0: xstrdup (xstrdup.c:38) |==19196== by 0x8049AB8: main (whatis.c:639) I don't care about the 39 bytes, since it happens only once, but the 60KB/query from main/xstrdup/xmalloc/malloc are enough to bother. Also, querying 3 disctinct names reveals that the regcomp allocation scales linearly, too: ==19223== 512 bytes in 2 blocks are definitely lost in loss record 22 of 31 ==19223== at 0x401B422: malloc (vg_replace_malloc.c:149) ==19223== by 0x40DC632: regcomp (regcomp.c:485) ==19223== by 0x804A954: main (whatis.c:754) ==19223== 16,904 (328 direct, 16,576 indirect) bytes in 2 blocks are definitely lost in loss record 26 of 31 ==19223== at 0x401B422: malloc (vg_replace_malloc.c:149) ==19223== by 0x401C90C: realloc (vg_replace_malloc.c:306) ==19223== by 0x40DC195: re_compile_internal (regcomp.c:774) ==19223== by 0x40DC6AA: regcomp (regcomp.c:504) ==19223== by 0x804A954: main (whatis.c:754) The first is 256 bytes per query; insignificant compared to the 8KB per query used in re_compile_internal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
