[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: