RPM Community Forums

Mailing List Message of <popt-devel>

Re: Memory leak with poptGetNextOpt

From: Seonkon Choi <seonkon.choi@windriver.com>
Date: Fri 12 Feb 2016 - 06:44:40 CET
Message-ID: <20160212054439.GA16515@sel-schoi0-d2.wrs.com>
On Fri, May 03, 2013 at 12:11:19PM -0400, Jeffrey Johnson wrote:
> 
> On May 2, 2013, at 5:56 PM, Karl Lindén wrote:
> 
> > Hello!
> > 
> > I am memory checking a program using the popt library but it seems as
> > there is some kind of memory leak in poptGetNextOpt. I have written a
> > small test program to show the issue. The program will basically just
> > take an integer argument and print the integer to the prompt. Of
> > course, the program works as expected, but valgrind records a leak.
> > 
> > I am attaching the test program. The valgrind output I will post
> > further down this mail.
> > 
> > I'm using popt version 1.16.
> > 
> > The program was compiled with the following command:
> > $ gcc -lpopt popt_test.c -o popt_test
> > 
> > $ valgrind --leak-check=full ./popt_test -i 890
> > ==1170== Memcheck, a memory error detector
> > ==1170== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> > ==1170== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> > ==1170== Command: ./popt_test -i 890
> > ==1170==
> > integer = 890
> > ==1170==
> > ==1170== HEAP SUMMARY:
> > ==1170==     in use at exit: 4 bytes in 1 blocks
> > ==1170==   total heap usage: 6 allocs, 5 frees, 882 bytes allocated
> > ==1170==
> > ==1170== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
> > ==1170==    at 0x4A099EB: malloc (in
> > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> > ==1170==    by 0x4C3372D: expandNextArg (popt.c:696)
> > ==1170==    by 0x4C34FD4: poptGetNextOpt (popt.c:1498)
> > ==1170==    by 0x400873: main (in /home/kalle/popt_test)
> > ==1170==
> > ==1170== LEAK SUMMARY:
> > ==1170==    definitely lost: 4 bytes in 1 blocks
> > ==1170==    indirectly lost: 0 bytes in 0 blocks
> > ==1170==      possibly lost: 0 bytes in 0 blocks
> > ==1170==    still reachable: 0 bytes in 0 blocks
> > ==1170==         suppressed: 0 bytes in 0 blocks
> > ==1170==
> > ==1170== For counts of detected and suppressed errors, rerun with: -v
> > ==1170== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
> > 
> > Should I do something to free the memory or is it some kind of bug?
> > 
> 
> The "leak" is actually a side effect of a design flaw returning strings to applications.
> 
> A proper fix would involve changing how returned option value memory is managed.
> 
> I'm not sure there's sufficient interest to justify a proper fix.
> 
> 73 de Jeff
> 

Before patch:
 ~snip~
 $ valgrind rpm -q --qf="1234" rpm
 ...
 ==21963==    definitely lost: 5 bytes in 1 blocks

 $ valgrind rpm -q --qf="1234" --qf="12" rpm
 ...
 ==21964==    definitely lost: 3 bytes in 1 blocks
 ~snip~

After patch:
 ~snip~
 $ valgrind rpm -q --qf="1234" rpm 
 ...
 ==21971==    definitely lost: 0 bytes in 0 blocks

 $ valgrind rpm -q --qf="1234" --qf="12" rpm
 ...
 ==21973==    definitely lost: 0 bytes in 0 blocks
~snip~


--- popt.c.orig	2016-02-12 12:28:52.670214800 +0900
+++ popt.c	2016-02-12 12:25:28.266214800 +0900
@@ -229,7 +229,7 @@ void poptResetContext(poptContext con)
     con->os->argb = PBM_FREE(con->os->argb);
     con->os->currAlias = NULL;
     con->os->nextCharArg = NULL;
-    con->os->nextArg = NULL;
+    con->os->nextArg = _free(con->os->nextArg);
     con->os->next = 1;			/* skip argv[0] */
 
     con->numLeftovers = 0;
Received on Fri Feb 12 13:00:03 2016
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.