Bug#159381: dselect: memory leaks (valgrind does its job ;)
On Tue, 3 Sep 2002, Bastian Kleineidam wrote:
> Package: dselect
> Version: 1.10.5
> Severity: normal
>
> Hi,
>
> alarmed by the segfaults in dselect I ran valgrind on the code and found
> leaks. Eeeek!
I've been using valgrind alot lately. The next version of dpkg and dselect
will have lots of memory fixes.
The segfault is fixed in 1.10.6.
> Start dselect, hit "update" and exit.
> ==19937== 20 bytes in 1 blocks are definitely lost in loss record 5 of 36
> ==19937== at 0x400436E8: __builtin_vec_new (vg_clientfuncs.c:156)
> ==19937== by 0x804D568: refreshmenu(void) (/home/calvin/src/dpkg-1.10.5/dselect/main.cc:392)
> ==19937== by 0x804D612: urq_menu(void) (/home/calvin/src/dpkg-1.10.5/dselect/main.cc:406)
> ==19937== by 0x804DA25: main (/home/calvin/src/dpkg-1.10.5/dselect/main.cc:496)
> ==19937==
> ==19937== 143 bytes in 1 blocks are definitely lost in loss record 20 of 36
> ==19937== at 0x400436E8: __builtin_vec_new (vg_clientfuncs.c:156)
> ==19937== by 0x804EFE0: readmethods(char const *, dselect_option **, int *) (/home/calvin/src/dpkg-1.10.5/dselect/methparse.cc:76)
> ==19937== by 0x804E674: ensureoptions(void) (/home/calvin/src/dpkg-1.10.5/dselect/method.cc:89)
> ==19937== by 0x804EBF1: runscript(char const *, char const *) (/home/calvin/src/dpkg-1.10.5/dselect/method.cc:209)
> ==19937==
>
> The first one is easy: lockfile is never delete[]d. So a simple
> "delete[] lockfile" before the return should suffice.
Already know of this one.
>
> The second one in methparse: pathbuf is not delete[]d in all
> possible code paths, especially in the return on ENOENT. I dont know
> what the ohshite function is doing - possibly bailing out, so thats
> another candidate.
This one too.
ohshit* and friends are error functions. You don't need to worry about
freeing memory if one of these are called.
> After fixing the above two bugs the "update and exit" had no more memory
> leaks (at least in my case).
> I am trying the "update, select, exit" procedure now, but it is very slow,
> eating a lot of memory.
> Filing this bug for now.
it'll take 1.1 gigs of memory.
Reply to: