Bug 119782
Summary: | memory leak in popt with int args | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Peter Snelling <snelling> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | notting, redhat-bugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-20 13:19:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Peter Snelling
2004-04-02 05:19:41 UTC
All arguments returned to the caller are malloc'd. It's up to the caller, not popt, to free. From the man page, it sounded like the application needs to call free for poptParseArgvString and poptDupArgv, but I don't see how that's the case for poptGetNextOpt. It's doesn't return any char pointers, and there are no extra parameters in this example to free. Any chance you could point out where I'm supposed to free something in the above example? Or, for that matter in the example in the man page which has the exact same memory leak if you use the option "--bps=1"? I grabbed the source for popt (1.7), and I'm now pretty confident that this is a real bug. It affects both string and int parms. Even if you free the string return, there is an additional string that isn't deallocated. Valgrind identified the realloc right at the end of "expandNextArg" as the source of the leak, and that line is clearly commented: t = realloc(t, strlen(t) + 1); /* XXX memory leak, hard to plug */ I'm not sure I understand this code well enough to be sure of how to fix this, but playing around with it a bit, the pointer to it gets null'd without being released in "poptResetContext", in this loop: while (con->os > con->optionStack) { cleanOSE(con->os--); } Notice that this look does a "cleanOSE" on every "con-os", except for the last one (where con->os == con->optionStack). The change that fixes this for me is adding a call to _free right after the loop: while (con->os > con->optionStack) { cleanOSE(con->os--); } _free(con->os->nextArg); Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. Note that any bug still open against Red Hat Linux on will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help. Yes, this bug still exists in current Fedora Core and RHEL releases. I've modified the "product" to be RHEL 4.1, which is what I'm currently running. The simplest way to verify this bug is to just use "rpm", which also has this bug, because it uses popt to parse it's parameters. So even a command as simple as "rpm --help" has a small memory leak, which can be seen using valgrind: $ valgrind --tool=memcheck --leak-check=yes rpm --help ... ==5326== LEAK SUMMARY: ==5326== definitely lost: 47 bytes in 1 blocks. ==5326== possibly lost: 0 bytes in 0 blocks. ==5326== still reachable: 9924 bytes in 141 blocks. ==5326== suppressed: 200 bytes in 1 blocks. The 1 block leak in popthelp.c has been fixed in rpm/popt cvs, will be in popt-1.10.8-0.11 when built. Meanwhile, there are other 1 time malloc's of data that cannot be free'd without changing popt's ABI. UPSTREAM or WONTFIX, your call. This problem is IMHO solved in Rawhide by popt-1.12-3. If not, please open a separate bug for Fedora to get this split of from RHEL. Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue. |