Re: [Clamav-users] Re: Clamav-devel massive memory leaks
Ola Thoresen wrote: I have captured several messages, and sent them to Thomas and Nigel. This seems to be an issue with some messages with attachments of Content-type: application/mac-binhex40; I can confirm this and I can confirm too that thomas' patch fixes the problem here. Stefan --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] Wait for next stable version or use CVS
Nigel Horne wrote: 4) Yes I am working on a solution and yes I am aware of it! I have just disabled binhex decoding in CVS while I further investigate this. I had success with the patch produced by Thomas Lamy at least for the 2 message that I have - are there some issues with that one ? Stefan --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] Re: Clamav-devel massive memory leaks
Ola Thoresen wrote: snip typically our mailrelays do run out of memory(1GB physical and 2Gb swap) after a few (maybe 10 to 15) minutes with the snapshots 20040113 and 20040119 under load We see this problem as well. On a couple of servers (Fedora Core 1, kernel 2.4.22-1.2149.nptl) with reasonably high load - 10 - 50 mails/second, clamd will run happily, using about 12 MB RAM, before it jumps to eat all available memory, before we encounter an oom-situation. We do not see this as often as you do - last few times has been 5 minutes, 3 hours, 4 hours and 17 hours apart. There is nothing in the logs or anywhere to suggest what is happening. Latest version we have tried is clamav-devel-20040129. ok after setting up a complicated testbed I managed to capture a message which results in a 2GB(!) memoryallocation of the latest snapshot 02012004 in less then 3 seconds ... unfortunatly I'm unable to forward the offending message (confidental information of a costumer) - but I can provide debugging output and any assistence necessary to fix this to any developer requesting it in private! Stefan --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] Re: Clamav-devel massive memory leaks
Franco Gasperino wrote: On Monday 02 February 2004 02:21 am, Stefan Kaltenbrunner wrote: ok after setting up a complicated testbed I managed to capture a message which results in a 2GB(!) memoryallocation of the latest snapshot 02012004 in less then 3 seconds ... unfortunatly I'm unable to forward the offending message (confidental information of a costumer) - but I can provide debugging output and any assistence necessary to fix this to any developer requesting it in private! Stefan Run the clam daemon through valgrind, trigger the leak, then shut it down normally. This should tell you exactly where it went wrong. I'm currently in private contact with Nigel to resolve this issue - and yes valgrind reports something like 1209160(!) errors on this simple 220k message. The whole debugging is getting quite difficult though because I'm still unable to forward the offending message due to privacy issues(work on getting permission to do so is ongoing). Stefan --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] is the virus db screwed up ?
Tomasz Papszun wrote: On Thu, 08 Jan 2004 at 19:25:36 +, Antony Stone wrote: Clamscan's working fine for me here (Linux 2.4.23, ClamAV 0.60, with the big database update just released, therefore 27645 signatures). 27645? How come? The database at the moment contains 19799 signatures. I think this happens everytime somebody updates an old installation that used the *.db file to the new *.cvd format without deleting the old files. clamd then somehow reports the sum of the signatures in these files(!). Stefan --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
[Clamav-users] segmentation fault with TCPAddr
There seems to be a problem with the new TCPAddr support in the latest snapshots - setting TCPSocket without setting TCPAddr (happens for example when upgrading from an older version) reliably segfaults upon startup on my system (Debian Testing/x86). Stefan --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] clamd dies forever!
Odhiambo Washington wrote: Okay, I know this is not good at all, that I run the CVS version of clamav on a production box. It's suicide. I've run the daily snapshots for some time without disappointment when it comes to supervising the service with daemontools. However, something in CVS seems to completely defy daemontools! For two days now, this has happened, but unfortunately I have not captured any data. Not core dump at all. for the record: we are seeing the same here - the latest snapshots sometimes just hang(especially under load - disabling pthread-support seems to help). Stefan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] clamd proposal and question
Marc Balmer wrote: Hi I have been running clamd 0.60 for quite some time now on our mail gateway in a milter setup (not the ClamAV milter, but our own one that speaks the clamd protocol). clamd in this version is not stable and I wonder if it is the server part or libclamav thats causing the trouble. hmm - we use it together with exiscan, and we have only seen it break under extremly high loads/unusual situations (i.e. enormous connection backlog due to the LDAP-loadbalancer going down). I suspect this problems occour when the maximum thread/backlog limits inside the clamd-daemon are reached. During light/normal load (we only have some 250k mails/day) the more recent snapshots do work reliable for us. I have worked a lot with Symantec AntiVirus Scan Engine and I think that their protocol is superior to the clamd protocol. SAVSE speaks ICAP plus an elaborate native protocol. I would like to see clamd support ICAP as well. The clamd native protocol is very problematic when connecting the server through a firewall, it has the same defects as FTP (the server choosing an arbitrary port number and handing it out to the client). while ICAP would be a really nice addition, the problematic behaviour of the STREAM-extension has already been discussed (on clamav-devel) and tomasz promised a solution for this :-) Stefan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] feature request for clam (STREAM mode)
Tomasz Kojm wrote: On Sun, 17 Aug 2003 19:38:10 +0200 Arkadiusz Miskiewicz [EMAIL PROTECTED] wrote: Hi, STREAM support is long awaited feature by me. Unfortunately it seems badly designed. The idea of the protocol is based on OpenAntiVirus ScannerDaemon's POST command, with some enhancements. Current protocol is: - connect with default clamav port (command connection) - send STREAM uppercase - clamd returns port number - we connect with that number and send data to be scanned there (data connection) That's it. Problems are: - if we want to scan few files we need to connect to reconnect to command connection every time, too - why? Why no multiple STREAM commands allowed? Do you mean STREAM should support an optional argument for a number of sockets clamd should start waiting on ? No problem. - data port is random so I need to open all ports on my firewall which is very This problem has been already reported a few days ago. The port number range will be configurable in clamav.conf. sad. Instead of this it would be great if I could send data over ,,command connection'' and don't use ,,data connection'' at all. Oh, I don't think this is a good idea - it will make the command socket a bottleneck because a scan process for may be long and we can't depend on the backlog argument of the listen() function due to portability reasons. I really, really dislike this solution which reminds me in some way to the (br0ken) ftp-protocol. A solution like this make any kind of loadbalancing(using a standard TCP balancing solution) nearly impossible. Any chance that this design could be changed to using a single TCP-Port. This would allow use to loadbalance/failover clamd easily between a large number of hosts (just like it's possible with spamd from the spamassassin package today). Stefan --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
