Looks like there is a mem leak with the standard make options on BSD platforms:
QUOTE | Hi all,
This is a brief summary from memory of the more excellent version of this mail before sylpheed crashed and ate the original. I lost all the strace and ktrace output I used in finding this :/ Sorry
While trying to figure out why I was getting the following errors on FreeBSD, I have tracked down an issue that is probably affecting others.
After running XMail for a few days, I found I wasn't able to check mail via POP3 (giving error about it not being able to open a file). In my system log I found:
Feb 28 14:31:59 krondor XMail[31933]: Unable to create file Feb 28 14:42:05 krondor last message repeated 5 times Feb 28 14:50:10 krondor last message repeated 4 times Feb 28 14:52:11 krondor XMail[31933]: Unable to create file Feb 28 14:53:29 krondor su: decker to root on /dev/ttyp0 Feb 28 14:54:12 krondor XMail[31933]: Unable to create file Feb 28 14:56:13 krondor XMail[31933]: Unable to create file Feb 28 14:58:14 krondor XMail[31933]: Unable to create file Feb 28 15:08:20 krondor last message repeated 5 times Feb 28 15:18:26 krondor last message repeated 5 times
A little checking showed the XMail has thousands of KQUEUE File Descriptors open.
Right after startup, no pop3 or smtp actions taken yet:
: lsof -n -p 10174 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME XMail 10174 root cwd VDIR 4,12 512 2 / XMail 10174 root rtd VDIR 4,12 512 2 / XMail 10174 root txt VREG 4,17 323624 353338 /var/email/bin/XMail XMail 10174 root txt VREG 4,12 141604 32936 /libexec/ld-elf.so.1 XMail 10174 root txt VREG 4,12 20260 14 /lib/libkvm.so.2 XMail 10174 root txt VREG 4,12 28644 13 /lib/libcrypt.so.2 XMail 10174 root txt VREG 4,18 102568 706635 /usr/lib/libc_r.so.5 XMail 10174 root txt VREG 4,18 834196 706807 /usr/lib/libstdc++.so.4 XMail 10174 root txt VREG 4,12 114504 15 /lib/libm.so.3 XMail 10174 root txt VREG 4,18 133164 706750 /usr/lib/libpthread.so.1 XMail 10174 root txt VREG 4,12 882780 24 /lib/libc.so.5 XMail 10174 root 0u IPv4 0xc34ae1c0 0t0 TCP *:6017 (LISTEN) XMail 10174 root 1u VCHR 2,2 0t0 16 /dev/null XMail 10174 root 2u VCHR 2,2 0t0 16 /dev/null XMail 10174 root 3u PIPE 0xc7cd7180 16384 ->0xc7cd722c XMail 10174 root 4u PIPE 0xc7cd722c 0 ->0xc7cd7180 XMail 10174 root 5u IPv4 0xc34b6000 0t0 TCP *:pop3 (LISTEN) XMail 10174 root 6u IPv4 0xc32af380 0t0 TCP *:smtp (LISTEN) XMail 10174 root 7u IPv4 0xc51838c0 0t0 TCP *:finger (LISTEN)
After checking one pop3 account:
(snip) XMail 10174 root 4u PIPE 0xc7cd722c 0 ->0xc7cd7180 XMail 10174 root 5u IPv4 0xc34b6000 0t0 TCP *:pop3 (LISTEN) XMail 10174 root 6u IPv4 0xc32af380 0t0 TCP *:smtp (LISTEN) XMail 10174 root 7u IPv4 0xc51838c0 0t0 TCP *:finger (LISTEN) XMail 10174 root 9u KQUEUE 0xc60df100 count=0, state=0
After checking the account again:
(snip) XMail 10174 root 6u IPv4 0xc32af380 0t0 TCP *:smtp (LISTEN) XMail 10174 root 7u IPv4 0xc51838c0 0t0 TCP *:finger (LISTEN) XMail 10174 root 9u KQUEUE 0xc60df100 count=0, state=0 XMail 10174 root 10u KQUEUE 0xd1c54380 count=0, state=0
I strace'd and ktrace'd XMail processes and found that it was calling kqueue() whenever it was doing a DNS lookup (gethostbyaddr was, I believe, the main culprit).
I started googling for "freebsd kqueue" and a variety of other words appended and found that this has been a problem for some time with FreeBSD. Dating back to 2003 I found posts regarding use of libc_r causing FD leaks with host lookups.
http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042423.html http://lists.freebsd.org/mailman/htdig/freebsd-bugs/2003-October/003809.html http://lists.freebsd.org/mailman/htdig/freebsd-bugs/2003-October/003810.html http://www.rhyolite.com/pipermail/dcc/2003/001409.html
I'm using FreeBSD 5.3-RELEASE (just cvsuped this morning) and still the patches given in the above URLs are not present in the source (though that's not an xmail problem).
After poking at the source a bit I found in Makefile.bsd that it was using libc_r when compiling, but I don't why.
ifeq ($(OSTYPE),OpenBSD) SYSTYPE = openbsd CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__OPENBSD__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE LDFLAGS = -lkvm -pthread -lc_r else ifeq ($(OSTYPE),NetBSD) SYSTYPE = netbsd CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__NETBSD__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE LDFLAGS = -lkvm -pthread -lc_r else ifeq ($(OSTYPE),Darwin) SYSTYPE = darwin CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__DARWIN__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE LDFLAGS = -lkvm -lpthread else SYSTYPE = freebsd CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__FREEBSD__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE LDFLAGS = -lkvm -lcrypt -pthread -lc_r endif
I removed " -lc_r " from the freebsd systype and compiled it normally (gmake -f Makefile.bsd), then installed the new binaries and voila, the FD leak is no more. I haven't tested this on OpenBSD or NetBSD, nor another version of FreeBSD for that matter. I strongly suggest removing -lc_r from the bsd makefile if it's not needed. Why is it there ? If anyone else is running XMail on FreeBSD, I'd like to know what version of freebsd and if you also see the KQUEUE issue, and if the fix I mentioned works for you so maybe Davide can change it in the main release to save fellow unsuspecting bsd users some grief
(side note, while testing this I removed all my patches to xmail, was testing with vanilla source)
Thanks, Darren
|
|