[Rpm-maint] [rpm-software-management/rpm] rpmbuild: %patch: fix a memory leak (#873)

Peter Jones notifications at github.com
Mon Sep 30 15:24:55 UTC 2019

While debugging something else, I noticed that when I run rpmbuild,
valgrind says:

==189844== HEAP SUMMARY:
==189844==     in use at exit: 12,088 bytes in 45 blocks
==189844==   total heap usage: 61,336 allocs, 61,291 frees, 28,975,297 bytes allocated
==189844== 24 bytes in 4 blocks are definitely lost in loss record 4 of 21
==189844==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==189844==    by 0x4FB5168: poptSaveArg (popt.c:1206)
==189844==    by 0x4FB5168: poptGetNextOpt (popt.c:1510)
==189844==    by 0x485EDF0: doPatchMacro (parsePrep.c:442)
==189844==    by 0x485F44A: parsePrep (parsePrep.c:513)
==189844==    by 0x4862C9F: parseSpec (parseSpec.c:924)
==189844==    by 0x40322C: buildForTarget.constprop.0 (rpmbuild.c:506)
==189844==    by 0x40340A: build.constprop.0 (rpmbuild.c:539)
==189844==    by 0x40267F: main (rpmbuild.c:701)

This looks pretty suspicious to me, so I went and looked at the code.
poptSaveArg() says:

        /* XXX memory leak, application is responsible for free. */
        arg.argv[0] = (con->os->nextArg) ? xstrdup(con->os->nextArg) : NULL;

This is the case where we've got a string argument pointer in
poptOption->arg.  In the case of %patch -P, we also keep a second copy
of it, obtained from poptGetNextArg(), which we *are* freeing.

This patch makes doPatchMacro() not need an extra allocated copy of
opt_P, and frees all the poptOption->arg strings that are allocated.

Signed-off-by: Peter Jones <pjones at redhat.com>
You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * rpmbuild: %patch: fix a memory leak

-- File Changes --

    M build/parsePrep.c (14)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20190930/39cbbbcd/attachment.html>

More information about the Rpm-maint mailing list