Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453086 - dmesg(8) memory leak
Summary: dmesg(8) memory leak
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: util-linux
Version: 5.1
Hardware: i386
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-27 07:21 UTC by masanari iida
Modified: 2008-07-22 12:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-22 12:50:00 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description masanari iida 2008-06-27 07:21:57 UTC
Description of problem:
test with valgrind, dmesg(8) seemed to forget to free a block.

Version-Release number of selected component (if applicable):
util-linux-2.13-0.47.el5

How reproducible:
always

Steps to Reproduce:
1. install valgrind-3.2.3-2 from Fedora.
2. valgrind --tool=memcheck --leak-check=full dmesg

  
Actual results:

==16082==
==16082== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1)
==16082== malloc/free: in use at exit: 131,080 bytes in 1 blocks.
==16082== malloc/free: 31 allocs, 30 frees, 133,063 bytes allocated.
==16082== For counts of detected errors, rerun with: -v
==16082== searching for pointers to 1 not-freed blocks.
==16082== checked 46,568 bytes.
==16082==
==16082== 131,080 bytes in 1 blocks are definitely lost in loss record 1 of 1
==16082==    at 0x40054E5: malloc (vg_replace_malloc.c:149)
==16082==    by 0x804887B: (within /bin/dmesg)
==16082==    by 0x35ADEB: (below main) (in /lib/libc-2.5.so)
==16082==
==16082== LEAK SUMMARY:
==16082==    definitely lost: 131,080 bytes in 1 blocks.   <==
==16082==      possibly lost: 0 bytes in 0 blocks.
==16082==    still reachable: 0 bytes in 0 blocks.
==16082==         suppressed: 0 bytes in 0 blocks.


Expected results:
No memory leak

Additional info:

[root@localhost ~]# rpm -qf /bin/dmesg
util-linux-2.13-0.47.el5

Comment 1 masanari iida 2008-06-27 09:13:00 UTC
Track down the leak with self compile version of dmesg(8),
valgrind pointed out line 121 in dmesg.c.

==19700== 131,080 bytes in 1 blocks are definitely lost in loss record 1 of 1
==19700==    at 0x40054E5: malloc (vg_replace_malloc.c:149)
==19700==    by 0x80487FB: main (dmesg.c:121)
==19700==

    119         if (bufsize) {
    120                 sz = bufsize + 8;
    121                 buf = (char *) malloc(sz);
    122                 n = klogctl(cmd, buf, sz);
    123         } else {
    124                 sz = 16392;
    125                 while (1) {
    126                         buf = (char *) malloc(sz);
    127                         n = klogctl(3, buf, sz);        /* read only */
    128                         if (n != sz || sz > (1<<28))
    129                                 break;
    130                         free(buf);
    131                         sz *= 4;
    132                 }


Comment 2 Karel Zak 2008-07-22 12:50:00 UTC
On Linux all memory is freed after process exit and many utils relies on this
feature. I don't think this as a fatal problem which should be fixed in RHEL update.

I'll close this report. Please, reopen, if you believe that the problem is
important and should be fixed.


Note You need to log in before you can comment on or make changes to this bug.