search for: vg_clientfunc

hi all after getting some (or - a lot) of messages from nagios, claiming asterisk to be down, I found this out... astping xxx times repeatedly, and the manager fails to start. this little script was used for testing. below, I've pasted the output from 'ps axfv' before and after the DoS, showing asterisk having allocated ~2GB RAM. roy #!/usr/bin/perl -w use strict; my $i = 0;

...I pulled the latest from cvs today and ran several tests and added more options to the CFLAGS in the Makefile. To start with, I ran valgrind against sshd & it comes up with this: ==24959== 112 bytes in 1 blocks are definitely lost in loss record 297 of 310 ==24959== at 0x40164650: malloc (vg_clientfuncs.c:100) ==24959== by 0x807A0D1: compat_init_setproctitle (setproctitle.c:236) ==24959== by 0x804D606: main (sshd.c:839) ==24959== by 0x403444CD: __libc_start_main (in /lib/libc-2.2.93.so) ==24959== by 0x804C4E0: (within /opt/openssh/sshd) ==24959== ==24959== LEAK SUMMARY: ==24959== d...

I am running 2.2.6 on a customer's site and everything has been perfect. However I noticed the other day that one of the two nmbd processes (it is a wins server) had grown to 13Mb over a two week period. I needed to update to the latest CVS version anyway and had hoped that something in that might fix things. Five days later and things are looking the same: nmbd started on Nov 9th: root

...> After a couple seconds "ctl-] quit" > > Then, /etc/rc.d/init.d/xinetd stop > > > > Valgrind reports the following: > > > > ==18939== 144 bytes in 1 blocks are definitely lost in loss record 36 of 45 > > ==18939== at 0x40160DB8: malloc (vg_clientfuncs.c:103) > > ==18939== by 0x804FE22: (within /usr/sbin/xinetd) > > ==18939== by 0x805A496: (within /usr/sbin/xinetd) > > ==18939== by 0x8053611: (within /usr/sbin/xinetd) > > ==18939== by 0x805340D: (within /usr/sbin/xinetd) > > ==18939== by 0x40294A...