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 < 100000000; ++i) {
> parseversion(&ver, "1.0.0", NULL);
> }
> return 0;
> }
>
> $ gcc leak.c -ldpkg && /usr/bin/time -v ./a.out 2>&1 | 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 < 100000000; ++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-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
