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! 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. 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. 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. Cheers, Bastian -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux treasure 2.4.18 #4 Sat Aug 10 18:10:03 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages dselect depends on: hi libc6 2.2.5-14 GNU C Library: Shared libraries an hi libncurses5 5.2.20020112a-8 Shared libraries for terminal hand hi libstdc++2.10-glibc2.2 1:2.95.4-11 The GNU stdc++ library -- no debconf information
