clamav-0.96 was just marked stable on x86 and emerged by portage. But when I try to start the new version it segfault. When I downgrade to old version 0.95.3 it works but I don't want to block stable packages by masking them because they segfault. I already tried removing everything in /var/lib/clamav and let freshclam rebuild the database but clamd still segfaults when starting after a database rebuild. Reproducible: Always Steps to Reproduce: 1. emerge clamav-0.96 (stable on x86) 2. start /etc/init.d/clamd start 3. watch segfault Actual Results: clamd segfault in ini script, I also found out that there's no need for starting through init script just running /usr/sbin/clamd als causes clamd to segfault Expected Results: starts the clamd daemon I already tried using the default conf script and rebuilding the database with no luck. 0.96 always segfault. 0.95.3 works perfectly. This is quite a big problem because it stops mailserver like exim from accepting mail and amavis to run because there is no spamd.sock socket to connect to. emerge --info Portage 2.1.8.3 (default/linux/x86/10.0/desktop/kde, gcc-4.3.4, glibc-2.10.1-r1, 2.6.32-tuxonice-r5 i686) ================================================================= System uname: Linux-2.6.32-tuxonice-r5-i686-Intel-R-_Pentium-R-_M_processor_1.60GHz-with-gentoo-1.12.13 Timestamp of tree: Tue, 13 Apr 2010 21:15:03 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.4.6, 2.5.4-r4, 2.6.4-r1 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.8.1-r1 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.8.5-r3, 1.9.6-r2, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/gentoo-release /home/p2p/.mldonkey /sbin/rc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache distlocks fixpackages metadata-transfer news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirror.netcologne.de/gentoo/ http://ftp.heanet.ie/pub/gentoo/ http://gentoo.tiscali.nl/ http://mirror.gentoo.no/ http://mirror.switch.ch/ftp/mirror/gentoo/ " LANG="en_US.utf8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1" LINGUAS="de en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/dev-zero /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa apache2 bash-complection bluetooth branding bzip2 cairo cdr clamav cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr dvdread emboss encode exif fam fbcon fbsplash ffmpeg firefox flac fortran ftp gdbm gif glade gnutls gpm gtk gtk-sharp hal iconv imagemagick imap innodb java jpeg jpg kde lcms libnotify mad maildir midi mikmod mng modules mozilla mp3 mp4 mpeg mudflap mysql mysqli ncurses nls nptl nptlonly odbc ogg opengl openmp pam pango pcmcia pcre pdf perl pic png ppds pppd python qt3support qt4 readline reflection samba sasl sdl semantic-desktop session spell spl sql ssl startup-notification svg sysfs tcpd tetex tiff truetype type1 unicode usb vcd vorbis webkit x264 x86 xcb xcomposite xml xorg xsl xslt xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Could you try moving everything out of /var/lib/clamav and then running freshclam to retrieve all new signature files? It worked for me, when it turned out clamav was trying to read files that hadn't been updated in a few years.
(In reply to comment #1) > Could you try moving everything out of /var/lib/clamav and then running > freshclam to retrieve all new signature files? It worked for me, when it turned > out clamav was trying to read files that hadn't been updated in a few years. > As stated in the bug description I already tried removing everything in /var/lib/clamav and let freshclam update the signature files. Unfortunately clamd still segfaults after freshclam has finished updating the signature files. In fact this was the first thing I tried because it was not the first time I had signature problems but this time segfault seems to be related to something else.
Hi, I confirm the problem even with a clean /var/lib/clamav/. Here is some additionnal info. The grsecurity reports the following. Apr 16 13:46:12 lune kernel: clamd[12209] general protection ip:ab8925ba sp:bf5e81f0 error:0 in libclamav.so.6.1.2[ab60f000+88b000] Apr 16 13:46:12 lune kernel: grsec: From 192.168.1.2: signal 11 sent to /usr/sbin/clamd[clamd:12209] uid/euid:103/103 gid/egid:442/442, parent /bin/bash[bash:14899] uid/euid:0/0 gid/egid:0/0 Linux lune 2.6.29-hardened #4 Sun Apr 11 13:06:28 EST 2010 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux Portage 2.1.8.3 (hardened/linux/x86/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.29-hardened i686) ================================================================= System uname: Linux-2.6.29-hardened-i686-AMD_Athlon-tm-with-gentoo-1.12.13 Timestamp of tree: Thu, 15 Apr 2010 19:45:01 +0000 app-shells/bash: 4.0_p37 dev-lang/python: 2.5.4-r3, 2.6.4-r1 dev-python/pycrypto: 2.1.0_beta1 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 3.4.6-r2, 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe -mmmx -msse" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=i686 -O3 -pipe -mmmx -msse" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="assume-digests autoconfig distlocks fixpackages metadata-transfer news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="http://ftp.swin.edu.au/gentoo http://mirror.pacific.net.au/linux/Gentoo ftp://mirror.pacific.net.au/linux/Gentoo http://ftp.club-internet.fr/pub/mirrors/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo http://ftp.swin.edu.au/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/hardened-development /var/lib/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.asia.gentoo.org/gentoo-portage" USE="berkdb bzip2 caps cli cracklib crypt cxx dri fam gdbm hardened iconv ipv6 logrotate mmx modules mudflap nptl nptlonly openmp pcre perl pic pppd python reflection session spl sse ssl sysfs unicode urandom x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 intel mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa via vmware voodoo" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hi all, Ok, very interesting ut to bring. For a customer, onto a not upgraded version of clamav (0.88.7) the clamd crashed this morning. I wan't able at all to restart it. To me, it seems the clam-av database is corrupted and/or doesn't match the format expected by clamd which lead to the crash. Could Gentoo guys up stream this to the relevant persons in clamav please ? Maybe this bug is affecting other distro... Thanks
By the way, clamav 0.95 doesn't seem to be affected by the problem...
same here /lib/rcscripts/sh/rc-daemon.sh: line 231: 8715 Segmentation fault /sbin/start-stop-daemon '--start' '--quiet' '--nicelevel' '3' '--exec' '/usr/sbin/clamd'
clamd[15396] general protection ip:b6fd56f7 sp:bf95a080 error:0 in libclamav.so.6.1.2[b6c5e000+b5e000] # ldd /usr/lib/libclamav.so.6.1.2 linux-gate.so.1 => (0xffffe000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb6b57000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libstdc++.so.6 (0xb6a69000) libz.so.1 => /lib/libz.so.1 (0xb6a47000) libbz2.so.1 => /lib/libbz2.so.1 (0xb6a2f000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6a15000) libm.so.6 => /lib/libm.so.6 (0xb69ef000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libgcc_s.so.1 (0xb69e1000) libc.so.6 => /lib/libc.so.6 (0xb6890000) libdl.so.2 => /lib/libdl.so.2 (0xb688c000) /lib/ld-linux.so.2 (0xb7720000)
seems CFLAGS="-O3" and other flags are much too agressive maybe filter out or hardcode somethings lesser in ebuild
Created attachment 228273 [details] patched ebuild which replaces -O3 with -O2 flags fixes the segfault with too aggressive -O3 flag
Seen here also, with -O3. The severity should be set to critical, as per "Critical: crashes, loss of data, severe memory leak" at http://bugs.gentoo.org/page.cgi?id=fields.html#bug_severity Who can review this and check it in?
I reported the crashing issue to the ClamAV bug tracking system (-> https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1984 <-). Upstream confirmed the segmentation fault. The problem is the flag "-ftree-vectorize". -O3 and above automatically enables this flag. So if you use -O3 and above you will have issues with ClamAV 0.96. The here in this bug report purposed fix/patch to replace -O3 with -O2 is not going to work. At least not for users having "-ftree-vectorize" in their flags. A (better IMHO) solution for the problem would be to add in the src_configure() section the following two lines: ------------------------------------------------------- is-flag -O[3-9] && append-flags -fno-tree-vectorize filter-flags -ftree-vectorize ------------------------------------------------------- I don't know if other arch then x86/amd64 are affected? Can any one here with an other arch then x86/amd64 try to reproduce that issue by adding "-ftree-vectorize" to his/her flags and try if ClamAV 0.96 is crashing with a segmentation fault? As long no other arch is reporting to have issues with "-ftree-vectorize" I would suggest to enclose the above two lines in a if condition and only let flag-o-matic filter/append flags for x86 or amd64 archs.
Now it is to wonder whether the bug is actually in clamav or it's GCC's code generation to be at fault.
just search bugzilla for vectorize / gcc issues. using -ftree-vectorize is a bad idea on x86 systems.
(In reply to comment #13) > just search bugzilla for vectorize / gcc issues. using -ftree-vectorize is a > bad idea on x86 systems. > If that switch is so bad on x86 then the GCC maintainers are the one to blame. Using "-O3" is pretty common and "-O3" enables "-ftree-vectorize" flag. I am not saying that "-ftree-vectorize" is good. I just find it not very responsible to enable that flag by default with "-O3" if it is producing that much trouble on x86 systems. I personally see no big issue in using "-ftree-vectorize". I am using it on all of my x86 systems and so far I have nothing special to report that does not work with it (beside ClamAV 0.96). Maybe the Ebuilds are handling all the cases where the flag could be an issue and remove/replace the flag from within the Ebuild? I don't know. All I can say is that on all systems that I use, I have installed many, many, many packages and all of them are working with "-ftree-vectorize". My personal viewpoint regarding ClamAV and -ftree-vectorize is: If ClamAV is breaking with -ftree-vectorize then the build system of ClamAV should internally handle that issue and remove/disable -ftree-vectorize on those platforms where ClamAV is breaking with the flag. That would be IMHO the user friendliest way of handling that problem. And the documentation of ClamAV should mention that building with -ftree-vectorize on x86 platforms is an issue and should be avoided.
let me rephrase ... using sse insns and -ftree-vectorize is known to cause problems (many of which are not bugs in gcc). if you do only one or the other, then things usually work fine. code that uses sse should probably be coded more defensively to make sure alignment requirements are met instead of assuming the system takes care of it.
(In reply to comment #15) > let me rephrase ... using sse insns and -ftree-vectorize is known to cause > problems (many of which are not bugs in gcc). if you do only one or the other, > then things usually work fine. code that uses sse should probably be coded > more defensively to make sure alignment requirements are met instead of > assuming the system takes care of it. > Yes. That is a statement that I find more appropriate. But let us get back to ClamAV 0.96. Would it be a big issue to add the workaround mentioned in #11 to the current ClamAV Ebuild till that issue gets resolved upstream? Is there anything holding us back doing that?
Created attachment 229557 [details] clamav-0.96-allocator.patch
Created attachment 229559 [details] clamav-0.96-attribute-aligned.patch
Applying those two patches solves the issue: clamav-0.96-allocator.patch clamav-0.96-attribute-aligned.patch The patches are from upstream.
Created attachment 229569 [details] clamav-0.96-allocator.patch
Created attachment 229571 [details] clamav-0.96-attribute-aligned.patch
Created attachment 229573 [details] clamav-0.96-allocator.patch
From 12/04/2010 this pachage is stable on x86, and the ebuild is not yet patched. I think that the priority for that bug must be increased.
(In reply to comment #23) > From 12/04/2010 this pachage is stable on x86, and the ebuild is not yet > patched. > What patch from 12/04/2010? > I think that the priority for that bug must be increased. > Feel free to increase severity and/or priority.
> Feel free to increase severity and/or priority. Touch not, lest ye be touched. a) changing the severity/priority doesn't actually do anything, and is just a way for developers to categorize their bugs b) you're talking about a problem caused by compiler flags we do not recommend, which immediately bumps it down the list c) the patches were posted yesterday (thanks steveb), so relax
Considering how old this bug is .. Is this still an issue for anyone? If not I will close the bug as OBSOLETE --- which I will also do if noone answers for a week or so.
