Hi!
On Sun, 2014-06-01 at 09:13:08 +0200, Johannes Schauer wrote:
whether the reason is the same I can't say but parseversion is still leaking
memory somehow:
It is still the same, it boils down to the way dpkg works and what
it has historically needed. So the database parsing code uses a
non-freeing memory allocator, think of it as an arena allocator.
#define LIBDPKG_VOLATILE_API 1
#include dpkg/dpkg.h
#include dpkg/version.h
int main()
{
struct dpkg_version ver;
int i;
for (i = 0; i 1; ++i) {
parseversion(ver, 1.0.0, NULL);
}
return 0;
}
$ gcc leak.c -ldpkg /usr/bin/time -v ./a.out 21 | grep Maximum
Maximum resident set size (kbytes): 1569096
Just as the original submitter I wanted to use parseversion to parse *LOTS* of
versions. My plans where thwarted when I discovered the memory leak.
I've got some code around to add support for custom allocators, but it
needs a major overhaul of the code. Meanwhile, as a workaround, you
could release the arena every N iterations, with something like:
,---
#define LIBDPKG_VOLATILE_API 1
#include dpkg/dpkg.h
#include dpkg/version.h
int main()
{
struct dpkg_version ver;
int i;
for (i = 0; i 1; ++i) {
parseversion(ver, 1.0.0, NULL);
if (i % 1000)
nffreeall();
}
return 0;
}
`---
But, take into account this will free all the dpkg database memory.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
