RPM Community Forums

Mailing List Message of <popt-devel>

Re: POPT's API has designed in memory leaks. What to do?

From: Mark Hatle <mark.hatle@windriver.com>
Date: Mon 07 Jun 2010 - 16:37:32 CEST
Message-ID: <4C0D042C.4040807@windriver.com>
The way I've usually addressed this is to either add an option to the library 
that changes the default behavior from strdup to passing the address with the 
expectation of const.

Either by adding const style prototypes/functions, or by using some mechanism to 
change the behavior of all of the functions.

My biggest concern is the potential retrofit of existing apps that expect the 
current behavior.. but I agree with many of the submitters.. popt really should 
be sending const points and then the app needs to strdup.

--Mark

Jeff Johnson wrote:
> I happen to have a valgrind trace on my screen that shows the issue
> 
> ==25160== 
> ==25160== 49 bytes in 1 blocks are still reachable in loss record 2 of 2
> ==25160==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
> ==25160==    by 0x314D9A: poptGetNextOpt (popt.c:1203)
> ==25160==    by 0x40697CD: rpmcliInit (poptALL.c:751)
> ==25160==    by 0x804AC45: main (rpmqv.c:385)
> ==25160== 
> 
> The "memory leak" is actually a POPT design feature. Every string
> returned from POPT is malloc'd so that an application
> can do whatever it wishes with the string without
> worrying about side effects of fiddling with the memory.
> 
> Unfortunately, POPT is mostly not used correctly, and the expectation is
> 	Hey POPT handles argv strings, I shouldn't _HAVE_ to manage those!?!
> 
> I get a tedious bug report every couple of months from otherwise honest
> attempts to use valgrind for application "squeaky clean" memory auditing.
> 
> Should this behavior be changed in POPT 2.0? It's a 1-liner change to remove
> a strdup() somewhere, but the change does have profound (but minor, who
> actually cares about a 49b 1-time memory leak these days) ramifications.
> 
> Meanwhile I'm way tired of explaining why its _NOT_ a memory leak, but rather
> buggy use of POPT.
> 
> Opinions welcomed.
> 
> 73 de Jeff
> ______________________________________________________________________
> POPT Library                                           http://rpm5.org
> Developer Communication List                       popt-devel@rpm5.org
Received on Mon Jun 7 17:15:44 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.