[Rpm-maint] [rpm-software-management/rpm] rpmbuild: %patch: fix a memory leak (#873)
notifications at github.com
Mon Sep 30 15:24:55 UTC 2019
While debugging something else, I noticed that when I run rpmbuild,
==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.
/* XXX memory leak, application is responsible for free. */
arg.argv = (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...
More information about the Rpm-maint