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; ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org