Red Hat Bugzilla – Bug 453086
dmesg(8) memory leak
Last modified: 2008-07-22 08:50:00 EDT
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
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 }
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.