|
| From: | GNU bug Tracking System |
| Subject: | [Emacs-bug-tracker] bug#8755: closed ("ls -l" leaks memory) |
| Date: | Sun, 29 May 2011 23:19:02 +0000 |
Your message dated Mon, 30 May 2011 00:15:30 +0100 with message-id <address@hidden> and subject line Re: bug#8755: "ls -l" leaks memory has caused the GNU bug report #8755, regarding "ls -l" leaks memory to be marked as done. (If you believe you have received this mail in error, please contact address@hidden) -- 8755: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8755 GNU Bug Tracking System Contact address@hidden with problems
--- Begin Message ---Subject: "ls -l" leaks memory According to valgrind, ls -l leaks memory. I have included the "coreutils version", "uname -a" information, Expected output from valgrind ("ls") and non-expected output ("ls -l"). Date: Sun, 29 May 2011 02:28:55 +0200
My first bug report ever, please tell me if something is wrong. I am using a dell e4300 laptop,
address@hidden:~$ ls --version
ls (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Richard M. Stallman and David MacKenzie.
address@hidden:~$ uname -a
Linux ola-Latitude-E4300 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
address@hidden:~$ valgrind --version
valgrind-3.6.1
Good run:
address@hidden:~$ valgrind ls
==4039== Memcheck, a memory error detector
==4039== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4039== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==4039== Command: ls
==4039==
Desktop Documents Downloads examples.desktop Music Pictures Public Templates Videos WATCHDOG
==4039==
==4039== HEAP SUMMARY:
==4039== in use at exit: 21,805 bytes in 16 blocks
==4039== total heap usage: 51 allocs, 35 frees, 59,016 bytes allocated
==4039==
==4039== LEAK SUMMARY:
==4039== definitely lost: 0 bytes in 0 blocks
==4039== indirectly lost: 0 bytes in 0 blocks
==4039== possibly lost: 0 bytes in 0 blocks
==4039== still reachable: 21,805 bytes in 16 blocks
==4039== suppressed: 0 bytes in 0 blocks
==4039== Rerun with --leak-check=full to see details of leaked memory
==4039==
==4039== For counts of detected and suppressed errors, rerun with: -v
==4039== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
Bad run:
address@hidden:~$ valgrind --leak-check=full ls -l
==4056== Memcheck, a memory error detector
==4056== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4056== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==4056== Command: ls -l
==4056==
total 40
drwxr-xr-x 4 ola ola 4096 2011-05-28 18:56 Desktop
drwxr-xr-x 2 ola ola 4096 2011-05-25 20:31 Documents
drwxr-xr-x 2 ola ola 4096 2011-05-28 07:41 Downloads
-rw-r--r-- 1 ola ola 179 2011-05-25 20:26 examples.desktop
drwxr-xr-x 2 ola ola 4096 2011-05-25 20:31 Music
drwxr-xr-x 2 ola ola 4096 2011-05-25 20:31 Pictures
drwxr-xr-x 2 ola ola 4096 2011-05-25 20:31 Public
drwxr-xr-x 2 ola ola 4096 2011-05-25 20:31 Templates
drwxr-xr-x 2 ola ola 4096 2011-05-25 20:31 Videos
-rw-r--r-- 1 ola ola 2278 2011-05-26 08:52 WATCHDOG
==4056==
==4056== HEAP SUMMARY:
==4056== in use at exit: 20,285 bytes in 38 blocks
==4056== total heap usage: 198 allocs, 160 frees, 80,622 bytes allocated
==4056==
==4056== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 29
==4056== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==4056== by 0x5556396: nss_parse_service_list (nsswitch.c:626)
==4056== by 0x5556948: __nss_database_lookup (nsswitch.c:167)
==4056== by 0x68A6553: ???
==4056== by 0x550992C: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
==4056== by 0x550921E: getpwuid (getXXbyYY.c:117)
==4056== by 0x40D4A9: ??? (in /bin/ls)
==4056== by 0x402D52: ??? (in /bin/ls)
==4056== by 0x40674F: ??? (in /bin/ls)
==4056== by 0x4081B0: ??? (in /bin/ls)
==4056== by 0x547BEFE: (below main) (libc-start.c:226)
==4056==
==4056== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 28 of 29
==4056== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==4056== by 0x5556396: nss_parse_service_list (nsswitch.c:626)
==4056== by 0x5556948: __nss_database_lookup (nsswitch.c:167)
==4056== by 0x68A451B: ???
==4056== by 0x5507F0C: getgrgid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
==4056== by 0x550765E: getgrgid (getXXbyYY.c:117)
==4056== by 0x40D649: ??? (in /bin/ls)
==4056== by 0x4067E5: ??? (in /bin/ls)
==4056== by 0x4081B0: ??? (in /bin/ls)
==4056== by 0x547BEFE: (below main) (libc-start.c:226)
==4056==
==4056== LEAK SUMMARY:
==4056== definitely lost: 120 bytes in 2 blocks
==4056== indirectly lost: 480 bytes in 20 blocks
==4056== possibly lost: 0 bytes in 0 blocks
==4056== still reachable: 19,685 bytes in 16 blocks
==4056== suppressed: 0 bytes in 0 blocks
==4056== Reachable blocks (those to which a pointer was found) are not shown.
==4056== To see them, rerun with: --leak-check=full --show-reachable=yes
==4056==
==4056== For counts of detected and suppressed errors, rerun with: -v
==4056== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
address@hidden:~$
/Ola
--- End Message ---
--- Begin Message ---Subject: Re: bug#8755: "ls -l" leaks memory Date: Mon, 30 May 2011 00:15:30 +0100 User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 On 29/05/11 01:28, Ola Olsson wrote: > <address@hidden>According to valgrind, ls -l leaks memory. I have > included the "coreutils version", "uname -a" information, Expected output > from valgrind ("ls") and non-expected output ("ls -l"). ls does leak but inconsequentially. Explicitly freeing the memory would only waste time managing the heap just before we'd exit anyway. cheers, Pádraig.
--- End Message ---
| [Prev in Thread] | Current Thread | [Next in Thread] |