Leo, I'm not getting anywhere on this. I installed your versions of Archive-Zip-1.23 and IO-Compress-Zlib-2.008 (along with your version of amavisd-new and perl, but on FreeBSD), but it doesn't break here with your sample message.
> >> The corresponding process never recovers and has to be killed with -9. > > It is spinning CPU, or just hanging? > > Just hanging, they are not consuming cpu. Thanks. Strange. > >> The emails that cause the trouble contain a zip file as attachment. > >> I have saved one of those mails, together with the debug-output of > >> amavis at the following address: > >> http://leo.kloburg.at/tmp/amavis-hang/ > Moreover I believe it might be a problem with the .zip or .exe handlers > in amavis. In that case, the virus-scanner won't help because amavis > will unpack the zip file anyways... > The only way I found so far is to disable zip in @decoders. Right. This seems to point guilt to the zip decoding Perl module, or more likely to its underlying C code. > I did already try it without custom rulesets. > I am using spamassassin with mysql, so Berkeley-DB isn't involved. > It is another run with the same mail. Looks like it hangs on totally > different places, so maybe process memory gets corrupted in an earlier > stage, maybe in zlib or other C-extensions which then causes hangs on > random locations? > However, I have extracted the do_unzip code into a small test script. > Running this script on the zip-file the same box doesn't produce the > above glibc error... And as far as I could see, the other unpackers are > external programs, so they shouldn't corrupt the amavisd process... Thanks. > The logs where produced with > $log_level = 5; > $sa_debug = '1,all'; > amavisd -c /etc/amavisd/amavisd.conf -d 5 debug >& debug.log > > Doesn't that produce the same result? That's alright. I just wasn't sure the SpamAssassin output was truly merged with amavisd log. With later versions of amavisd this is somewhat easier, as SpamAssassin logging is captured by amavisd handler and written to amavis log. I wonder if it would help upgrading Archive::Zip to a current version (1.26), along with its underlying Compress::Zlib (2.015), Compress-Raw-Zlib (2.020), IO-Compress (2.020). The main suspect is Compress-Raw-Zlib, as it uses C code, although I don't see anything suspicious in its Changes file. Tracking this down will require hands-on access to some platform where it can be reproduced at will, perhaps running it under a Perl debugger to see in what code region it hangs. Mark ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
