ClamAV 0.96.2 not working on FreeBSD 7.1
Hi, I'm experiencing problems running ClamAV 0.96.2 on FreeBSD 7.1 (i386). The clamd will stop working immediately after startup. The process is still there, but unresponsive: # /usr/local/bin/clamdtop [...] Connecting to: /var/run/clamav/clamd.sock /var/run/clamav/clamd.sock: Resource temporarily unavailable I found that it works on FreeBSD 8.0 without any problems, so a change in version 0.96.2 possiblity broke compatiblity with older versions of FreeBSD. Version 0.96.1 runs without any problems on FreeBSD 7.1. Is anyone else seeing this problem? I am able to reproduce this on all my 7.1 boxes. FYI, I've opened a bug report at ClamAV: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2235 Thanks - Frank ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/149534: [maintainer-update] multimedia/mplayer and mencoder dependency corrections
Synopsis: [maintainer-update] multimedia/mplayer and mencoder dependency corrections Responsible-Changed-From-To: bapt->freebsd-ports Responsible-Changed-By: bapt Responsible-Changed-When: Fri Aug 27 12:18:03 UTC 2010 Responsible-Changed-Why: Unable to find a fix so back to the pool. Sorry http://www.freebsd.org/cgi/query-pr.cgi?pr=149534 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ClamAV 0.96.2 not working on FreeBSD 7.1
On 27/08/2010 12:39, Frank Wall wrote: Hi, I'm experiencing problems running ClamAV 0.96.2 on FreeBSD 7.1 (i386). The clamd will stop working immediately after startup. The process is still there, but unresponsive: i had something similar and eventually found that disabling JIT Bytecode compiler option, returned it to being stable. This only happened on one of my boxes though so i figured it was 'me'. Paul. -- - Paul Macdonald IFDNRG Ltd Web and video hosting - t: 0131 5548070 m: 07534206249 e: p...@ifdnrg.com w: http://www.ifdnrg.com - IFDNRG 40 Maritime Street Edinburgh EH6 6SA - ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ClamAV 0.96.2 not working on FreeBSD 7.1
On Fri, Aug 27, 2010 at 01:20:23PM +0100, Paul Macdonald wrote: > > i had something similar and eventually found that disabling JIT > Bytecode compiler option, returned it to being stable. > This only happened on one of my boxes though so i figured it was 'me'. Thanks for the hint. Setting "Bytecode" to "no" does the trick. Now version 0.96.2 runs without any problems on FreeBSD 7.1. But I don't consider this a "solution", it's a workaround to get things going again. Maybe the ClamAV people will provide a fix for this issue. Thanks - Frank ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
i7z for FreeBSD
How hard would it be to port i7z to FreeBSD? Seems like a very useful tool. http://code.google.com/p/i7z/ Emanuel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/149534: [maintainer-update] multimedia/mplayer and mencoder dependency corrections
Synopsis: [maintainer-update] multimedia/mplayer and mencoder dependency corrections Responsible-Changed-From-To: freebsd-ports->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 27 13:59:43 UTC 2010 Responsible-Changed-Why: Canonicalize assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=149534 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
why is archivers/xz marked as IGNORE?
Hi, why is archivers/xz marked as IGNORE? pkg_delete: package 'xz-4.999.9_1' is required by these other packages and may not be deinstalled: gtar-1.23_2 kdeutils-3.5.10_6 Heino ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: why is archivers/xz marked as IGNORE?
Hi! > why is archivers/xz marked as IGNORE? > > > > pkg_delete: package 'xz-4.999.9_1' is required by these other packages > and may not be deinstalled: > gtar-1.23_2 > kdeutils-3.5.10_6 Because it became part of the base system with 8.1. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
Hi! > I have a few clamav instances running in jails on 32-bit hosts without > any issues. A few days ago one of these jails was migrated to a 64-bit > host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried. > > The issue seems specific to 32bit/64bit compatibility. I have a gdb > session available here: http://gist.github.com/549964 > > Any thoughts on if this is possible? Try Bytecode no in clamd.conf ? -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On 8/27/10 12:33 PM, Kurt Jaeger wrote: > Hi! > >> I have a few clamav instances running in jails on 32-bit hosts without >> any issues. A few days ago one of these jails was migrated to a 64-bit >> host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried. >> >> The issue seems specific to 32bit/64bit compatibility. I have a gdb >> session available here: http://gist.github.com/549964 >> >> Any thoughts on if this is possible? > > Try > > Bytecode no > > in clamd.conf ? > It was set to 'yes' initially. I thought it was disabled with building without JIT. At any rate, no, it still segfaults with the same backtrace. Regards, -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
Hello, I have a few clamav instances running in jails on 32-bit hosts without any issues. A few days ago one of these jails was migrated to a 64-bit host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried. The issue seems specific to 32bit/64bit compatibility. I have a gdb session available here: http://gist.github.com/549964 Any thoughts on if this is possible? Regards, -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On 8/27/10 12:54 PM, Jeremy Chadwick wrote: > On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: >> On 8/27/10 12:33 PM, Kurt Jaeger wrote: >>> Hi! >>> I have a few clamav instances running in jails on 32-bit hosts without any issues. A few days ago one of these jails was migrated to a 64-bit host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried. The issue seems specific to 32bit/64bit compatibility. I have a gdb session available here: http://gist.github.com/549964 Any thoughts on if this is possible? >>> >>> Try >>> >>> Bytecode no >>> >>> in clamd.conf ? >>> >> >> It was set to 'yes' initially. I thought it was disabled with building >> without JIT. At any rate, no, it still segfaults with the same backtrace. > > 1) Is clamd built with debugging symbols enabled? If not, you might want > to rebuild it with such, else it might be difficult to debug the > problem. > It wasn't initially, but is now. > Also, if the segfault happens after performing the above, can you > provide output from "bt full" instead of just "bt"? > Of course. The new backtrace is here: http://gist.github.com/553734 > 2) Was the software rebuilt from source after the upgrade from i386 to > amd64, or are you expecting the software to work without any hitches > running on amd64 with lib32 (32-bit compatibility libaries)? The latter > is not always possible/the case. > clamav was rebuilt from ports. I previously went as far as downgrading to the previous version, to rule out something between 0.96.1 and 0.96.2; same results there. > I have no familiarity with the software or functions in question, but an > initial guess would be that some piece of the code is making assumptions > about the size of pointers (expecting 4 (32-bit) rather than 8 > (64-bit)). Speculative on my part, but I ponder such when seeing code > like somefunc(sizeof(int)). > Thanks and regards, -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: > On 8/27/10 12:33 PM, Kurt Jaeger wrote: > > Hi! > > > >> I have a few clamav instances running in jails on 32-bit hosts without > >> any issues. A few days ago one of these jails was migrated to a 64-bit > >> host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when > >> queried. > >> > >> The issue seems specific to 32bit/64bit compatibility. I have a gdb > >> session available here: http://gist.github.com/549964 > >> > >> Any thoughts on if this is possible? > > > > Try > > > > Bytecode no > > > > in clamd.conf ? > > > > It was set to 'yes' initially. I thought it was disabled with building > without JIT. At any rate, no, it still segfaults with the same backtrace. 1) Is clamd built with debugging symbols enabled? If not, you might want to rebuild it with such, else it might be difficult to debug the problem. Also, if the segfault happens after performing the above, can you provide output from "bt full" instead of just "bt"? 2) Was the software rebuilt from source after the upgrade from i386 to amd64, or are you expecting the software to work without any hitches running on amd64 with lib32 (32-bit compatibility libaries)? The latter is not always possible/the case. I have no familiarity with the software or functions in question, but an initial guess would be that some piece of the code is making assumptions about the size of pointers (expecting 4 (32-bit) rather than 8 (64-bit)). Speculative on my part, but I ponder such when seeing code like somefunc(sizeof(int)). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: why is archivers/xz marked as IGNORE?
Kurt Jaeger wrote: > Hi! > >> why is archivers/xz marked as IGNORE? >> >> >> >> pkg_delete: package 'xz-4.999.9_1' is required by these other packages >> and may not be deinstalled: >> gtar-1.23_2 >> kdeutils-3.5.10_6 > > Because it became part of the base system with 8.1. Ah, how can I gat this out of the dependecies? Heino ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: why is archivers/xz marked as IGNORE?
Hi,
> On Fri, 27 Aug 2010 19:16:15 +0200
> Heino Tiedemann said:
rotkaps> Kurt Jaeger wrote:
> Hi!
>
>> why is archivers/xz marked as IGNORE?
>>
>>
>>
>> pkg_delete: package 'xz-4.999.9_1' is required by these other packages
>> and may not be deinstalled:
>> gtar-1.23_2
>> kdeutils-3.5.10_6
>
> Because it became part of the base system with 8.1.
rotkaps_spam_trap> Ah, how can I gat this out of the dependecies?
rotkaps_spam_trap> Heino
Rebuild and reinstall gtar and kdeutils.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: why is archivers/xz marked as IGNORE?
On 08/27/2010 07:21 AM, Heino Tiedemann wrote: Hi, why is archivers/xz marked as IGNORE? To fix up your system without rebuilding everything you could use ports-mgmt/portmaster: portmaster -d -e xz portmaster --check-depends When running the 2nd command when it tells you that xz is listed as a dependency but there is no installed version you can say "yes" when it asks if you want to remove the dependency data. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 01:06:49PM -0400, Glen Barber wrote: > On 8/27/10 12:54 PM, Jeremy Chadwick wrote: > > On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: > >> On 8/27/10 12:33 PM, Kurt Jaeger wrote: > >>> Hi! > >>> > I have a few clamav instances running in jails on 32-bit hosts without > any issues. A few days ago one of these jails was migrated to a 64-bit > host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when > queried. > > The issue seems specific to 32bit/64bit compatibility. I have a gdb > session available here: http://gist.github.com/549964 > > Any thoughts on if this is possible? > >>> > >>> Try > >>> > >>> Bytecode no > >>> > >>> in clamd.conf ? > >>> > >> > >> It was set to 'yes' initially. I thought it was disabled with building > >> without JIT. At any rate, no, it still segfaults with the same backtrace. > > > > 1) Is clamd built with debugging symbols enabled? If not, you might want > > to rebuild it with such, else it might be difficult to debug the > > problem. > > > > It wasn't initially, but is now. > > > Also, if the segfault happens after performing the above, can you > > provide output from "bt full" instead of just "bt"? > > > > Of course. The new backtrace is here: http://gist.github.com/553734 I want to make sure I understand the environment -- on a native i386 (32-bit) FreeBSD host, the software works fine. But on a native amd64 (64-bit) FreeBSD host, the software segfaults. Correct? If so -- it appears as if the system you're providing the backtrace from is a 32-bit system, or within a 32-bit environment? I would expect to see 64-bit addresses in the backtrace, yet they're all 32-bit. I'm not familiar with jailed environments (or the concept/possibility of running a mixed-architecture jail (e.g. 64-bit host OS with 32-bit jails)). I don't use lib32 on my amd64 systems. I did take a look at the clamav code itself (I'd have to spend a few hundred lines outlining it here and would rather not). My guess is that there's a conflict between what the running OS architecture is and what the build process determines the architecture is. Given that you have jails, and possibly a mixed architecture environment on a single host (e.g. 64-bit host OS with 32-bit jails), can you explain exactly how you go about building clamav, followed by how you go about running it? Thanks. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On 8/27/10 1:32 PM, Jeremy Chadwick wrote: >> Of course. The new backtrace is here: http://gist.github.com/553734 > > I want to make sure I understand the environment -- on a native i386 > (32-bit) FreeBSD host, the software works fine. But on a native amd64 > (64-bit) FreeBSD host, the software segfaults. Correct? > The clamav instance runs on a 64-bit host in a 32-bit jail. In a 32-bit host/32-bit jail environment, the software runs fine, as you suggest above. > If so -- it appears as if the system you're providing the backtrace from > is a 32-bit system, or within a 32-bit environment? I would expect to > see 64-bit addresses in the backtrace, yet they're all 32-bit. > > I'm not familiar with jailed environments (or the concept/possibility of > running a mixed-architecture jail (e.g. 64-bit host OS with 32-bit > jails)). I don't use lib32 on my amd64 systems. > To be honest, this is the first non-base software I've had an issue with in a mixed-arch environment. > I did take a look at the clamav code itself (I'd have to spend a few > hundred lines outlining it here and would rather not). My guess is that > there's a conflict between what the running OS architecture is and what > the build process determines the architecture is. > > Given that you have jails, and possibly a mixed architecture environment > on a single host (e.g. 64-bit host OS with 32-bit jails), can you > explain exactly how you go about building clamav, followed by how you go > about running it? > The build is done from ports with no special options excluding the latest build, being: make -DWITH_DEBUG DEBUG_FLAGS=-g The only make.conf entry is PERL_VERSION=5.10.1. The clamd service runs under djb's supervise (/usr/local/sbin/clamd). Additionally, port builds were done after setting UNAME_m and UNAME_p [1], but I haven't had luck with that overriding the machine hardware type. If this provides any clues, here's what file(1) sees, as well as ldd: % file /usr/local/sbin/clamd /usr/local/sbin/clamd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, not stripped % ldd /usr/local/sbin/clamd /usr/local/sbin/clamd: libclamav.so.7 => /usr/local/lib/libclamav.so.7 (0x280ac000) libz.so.5 => /lib/libz.so.5 (0x281f8000) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x2820a000) libm.so.5 => /lib/libm.so.5 (0x2821b000) libthr.so.3 => /lib/libthr.so.3 (0x28235000) libc.so.7 => /lib/libc.so.7 (0x2824a000) [1] - http://www.mail-archive.com/freebsd-am...@freebsd.org/msg00248.html Cheers, -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeRADIUS and E-Directory
Hello, I've a question about compiling FreeRADIUS with E-Directory support. In the FreeRADIUS 1.x branch, there is a toggle in options for compiling with support for e-dir. In the 2.x branch, there is no toggle. I have sent an e-mail to the FreeRADIUS mailing list and had it confirmed that FR still needs to be compiled with the e-dir option, but they were not sure how to do that in FreeBSD. While we are currently only checking MAC addresses, I would like to switch to usernames in order to tell who is using which computer when and need to tie into our Novell servers. Please reply to the list as I check the list with a different e-mail address. (It's an exchange account and I've found my mail to the list bounces.) Thanks in advance! -- John McDonnell Penn Cambria School District mcdon...@pcam.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 01:58:25PM -0400, Glen Barber wrote: > On 8/27/10 1:32 PM, Jeremy Chadwick wrote: > >> Of course. The new backtrace is here: http://gist.github.com/553734 > > > > I want to make sure I understand the environment -- on a native i386 > > (32-bit) FreeBSD host, the software works fine. But on a native amd64 > > (64-bit) FreeBSD host, the software segfaults. Correct? > > > > The clamav instance runs on a 64-bit host in a 32-bit jail. In a 32-bit > host/32-bit jail environment, the software runs fine, as you suggest above. > > > If so -- it appears as if the system you're providing the backtrace from > > is a 32-bit system, or within a 32-bit environment? I would expect to > > see 64-bit addresses in the backtrace, yet they're all 32-bit. > > > > I'm not familiar with jailed environments (or the concept/possibility of > > running a mixed-architecture jail (e.g. 64-bit host OS with 32-bit > > jails)). I don't use lib32 on my amd64 systems. > > > > To be honest, this is the first non-base software I've had an issue with > in a mixed-arch environment. Okay, so it's sort of what I thought. Your system has a series of include files on it that are for amd64 (64-bit), but clamav, when built within a 32-bit jail on that system, is (probably -- no proof, but it's an educated guess based on what's happening) detecting some 64-bit pieces through include files and making some incorrect assumptions about the size of some types. I'd really need to set up a testbed system/VM and get full instructions from start to finish on how to set up a 32-bit jail and so on, given that I've never done it. Otherwise, you're probably going to need to find someone who has a similar setup and can reproduce the problem, or give a developer root-level access to your system. > > I did take a look at the clamav code itself (I'd have to spend a few > > hundred lines outlining it here and would rather not). My guess is that > > there's a conflict between what the running OS architecture is and what > > the build process determines the architecture is. > > > > Given that you have jails, and possibly a mixed architecture environment > > on a single host (e.g. 64-bit host OS with 32-bit jails), can you > > explain exactly how you go about building clamav, followed by how you go > > about running it? > > The build is done from ports with no special options excluding the > latest build, being: > > make -DWITH_DEBUG DEBUG_FLAGS=-g > > The only make.conf entry is PERL_VERSION=5.10.1. > > The clamd service runs under djb's supervise (/usr/local/sbin/clamd). > Additionally, port builds were done after setting UNAME_m and UNAME_p > [1], but I haven't had luck with that overriding the machine hardware type. > > If this provides any clues, here's what file(1) sees, as well as ldd: > > % file /usr/local/sbin/clamd > /usr/local/sbin/clamd: ELF 32-bit LSB executable, Intel 80386, version 1 > (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, not > stripped > > % ldd /usr/local/sbin/clamd > /usr/local/sbin/clamd: > libclamav.so.7 => /usr/local/lib/libclamav.so.7 (0x280ac000) > libz.so.5 => /lib/libz.so.5 (0x281f8000) > libbz2.so.4 => /usr/lib/libbz2.so.4 (0x2820a000) > libm.so.5 => /lib/libm.so.5 (0x2821b000) > libthr.so.3 => /lib/libthr.so.3 (0x28235000) > libc.so.7 => /lib/libc.so.7 (0x2824a000) > > [1] - http://www.mail-archive.com/freebsd-am...@freebsd.org/msg00248.html Right -- I understand the binary is 32-bit, but that's not where the problem lies (based on my guess). The binary obviously runs, or else you wouldn't be seeing a segfault or even get a remotely coherent backtrace in gdb. I'm not sure how to explain this in a way that's easily understandable (I'm assuming you're not a programmer. :-) ). My guess is that during compile-time, the compiler is kicking out some code that's based on sizeof(int) == 8 (64-bit), when that shouldn't be the case in a 32-bit environment. Include files could cause this problem too. There may be some "black magic" in the ports infrastructure (maybe even on a per-port basis) to work around this problem that the clamav port isn't making use of. I really don't know. Sorry I can't be of more help. I'm one of those guys who if he needs a 32-bit and 64-bit system, buys two physical systems. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On 8/27/10 2:20 PM, Jeremy Chadwick wrote: >> To be honest, this is the first non-base software I've had an issue with >> in a mixed-arch environment. > > Okay, so it's sort of what I thought. Your system has a series of > include files on it that are for amd64 (64-bit), but clamav, when built > within a 32-bit jail on that system, is (probably -- no proof, but it's > an educated guess based on what's happening) detecting some 64-bit > pieces through include files and making some incorrect assumptions about > the size of some types. > > I'd really need to set up a testbed system/VM and get full instructions > from start to finish on how to set up a 32-bit jail and so on, given > that I've never done it. Otherwise, you're probably going to need to > find someone who has a similar setup and can reproduce the problem, or > give a developer root-level access to your system. > I've also posted to the clamav-users@ list (but it was the backtrace before -DWITH_DEBUG was set), but haven't had a reply. Unfortunately, this particular setup, I can't provide root access, however I might be able to do so on one of my personal machines. It will be some time before I get everything set up properly though. [snip] > > I'm not sure how to explain this in a way that's easily understandable > (I'm assuming you're not a programmer. :-) ). My guess is that during > compile-time, the compiler is kicking out some code that's based on > sizeof(int) == 8 (64-bit), when that shouldn't be the case in a 32-bit > environment. Include files could cause this problem too. > Not a C programmer. :-) > There may be some "black magic" in the ports infrastructure (maybe even > on a per-port basis) to work around this problem that the clamav port > isn't making use of. I really don't know. > > Sorry I can't be of more help. I'm one of those guys who if he needs a > 32-bit and 64-bit system, buys two physical systems. > No problem. I appreciate you taking the time to look at it this far. Cheers, -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
Hello Kostik, On 8/27/10 2:58 PM, Kostik Belousov wrote: >> Of course. The new backtrace is here: http://gist.github.com/553734 > > I suspect that this was fixed in r210796/HEAD and r211138/RELENG_8. > I will check this out on a test machine. Thanks. >> >>> 2) Was the software rebuilt from source after the upgrade from i386 to >>> amd64, or are you expecting the software to work without any hitches >>> running on amd64 with lib32 (32-bit compatibility libaries)? The latter >>> is not always possible/the case. >>> >> >> clamav was rebuilt from ports. I previously went as far as downgrading >> to the previous version, to rule out something between 0.96.1 and >> 0.96.2; same results there. > > Was clamav rebuilt in the 32-bit jail ? At least your backtrace shows > 32-bit image being executed. > Yes, this is correct. Thanks again, -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 09:58:38PM +0300, Kostik Belousov wrote: > On Fri, Aug 27, 2010 at 01:06:49PM -0400, Glen Barber wrote: > > On 8/27/10 12:54 PM, Jeremy Chadwick wrote: > > > On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: > > >> On 8/27/10 12:33 PM, Kurt Jaeger wrote: > > >>> Hi! > > >>> > > I have a few clamav instances running in jails on 32-bit hosts without > > any issues. A few days ago one of these jails was migrated to a 64-bit > > host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when > > queried. > > > > The issue seems specific to 32bit/64bit compatibility. I have a gdb > > session available here: http://gist.github.com/549964 > > > > Any thoughts on if this is possible? > > >>> > > >>> Try > > >>> > > >>> Bytecode no > > >>> > > >>> in clamd.conf ? > > >>> > > >> > > >> It was set to 'yes' initially. I thought it was disabled with building > > >> without JIT. At any rate, no, it still segfaults with the same > > >> backtrace. > > > > > > 1) Is clamd built with debugging symbols enabled? If not, you might want > > > to rebuild it with such, else it might be difficult to debug the > > > problem. > > > > > > > It wasn't initially, but is now. > > > > > Also, if the segfault happens after performing the above, can you > > > provide output from "bt full" instead of just "bt"? > > > > > > > Of course. The new backtrace is here: http://gist.github.com/553734 > I suspect that this was fixed in r210796/HEAD and r211138/RELENG_8. Would that be these two? http://svn.freebsd.org/viewvc/base?view=revision&revision=210796 http://svn.freebsd.org/viewvc/base/head/sys/compat/freebsd32/freebsd32_misc.c?r1=210796&r2=210795&pathrev=210796 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/freebsd32/freebsd32_misc.c.diff?r1=1.110;r2=1.111;f=h http://svn.freebsd.org/viewvc/base?view=revision&revision=211138 http://svn.freebsd.org/viewvc/base/stable/8/sys/compat/freebsd32/freebsd32_misc.c?r1=211138&r2=211137&pathrev=211138 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/freebsd32/freebsd32_misc.c.diff?r1=1.93.2.13;r2=1.93.2.14;f=h Based on this PR? http://www.freebsd.org/cgi/query-pr.cgi?pr=149227 > > > 2) Was the software rebuilt from source after the upgrade from i386 to > > > amd64, or are you expecting the software to work without any hitches > > > running on amd64 with lib32 (32-bit compatibility libaries)? The latter > > > is not always possible/the case. > > > > > > > clamav was rebuilt from ports. I previously went as far as downgrading > > to the previous version, to rule out something between 0.96.1 and > > 0.96.2; same results there. > Was clamav rebuilt in the 32-bit jail ? At least your backtrace shows > 32-bit image being executed. > > > > > > I have no familiarity with the software or functions in question, but an > > > initial guess would be that some piece of the code is making assumptions > > > about the size of pointers (expecting 4 (32-bit) rather than 8 > > > (64-bit)). Speculative on my part, but I ponder such when seeing code > > > like somefunc(sizeof(int)). > Absolute nonsense. Well, it's not really nonsense, but I'd rather not go to great lengths to show how it's possible. In this specific case it would end up depending on what CMSG_LEN() does. clamav does have some code where CMSG_LEN() can get overridden (supposedly for Solaris 8 only). This is why I said I'd rather not post hundreds of lines of code; it's one of those situations that's demonstrated when debugged in real-time and not entirely by source analysis. Anyway, as I said, I don't have familiarity with environments where 32-bit code is being run on 64-bit archs. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 01:06:49PM -0400, Glen Barber wrote: > On 8/27/10 12:54 PM, Jeremy Chadwick wrote: > > On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: > >> On 8/27/10 12:33 PM, Kurt Jaeger wrote: > >>> Hi! > >>> > I have a few clamav instances running in jails on 32-bit hosts without > any issues. A few days ago one of these jails was migrated to a 64-bit > host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when > queried. > > The issue seems specific to 32bit/64bit compatibility. I have a gdb > session available here: http://gist.github.com/549964 > > Any thoughts on if this is possible? > >>> > >>> Try > >>> > >>> Bytecode no > >>> > >>> in clamd.conf ? > >>> > >> > >> It was set to 'yes' initially. I thought it was disabled with building > >> without JIT. At any rate, no, it still segfaults with the same backtrace. > > > > 1) Is clamd built with debugging symbols enabled? If not, you might want > > to rebuild it with such, else it might be difficult to debug the > > problem. > > > > It wasn't initially, but is now. > > > Also, if the segfault happens after performing the above, can you > > provide output from "bt full" instead of just "bt"? > > > > Of course. The new backtrace is here: http://gist.github.com/553734 I suspect that this was fixed in r210796/HEAD and r211138/RELENG_8. > > > 2) Was the software rebuilt from source after the upgrade from i386 to > > amd64, or are you expecting the software to work without any hitches > > running on amd64 with lib32 (32-bit compatibility libaries)? The latter > > is not always possible/the case. > > > > clamav was rebuilt from ports. I previously went as far as downgrading > to the previous version, to rule out something between 0.96.1 and > 0.96.2; same results there. Was clamav rebuilt in the 32-bit jail ? At least your backtrace shows 32-bit image being executed. > > > I have no familiarity with the software or functions in question, but an > > initial guess would be that some piece of the code is making assumptions > > about the size of pointers (expecting 4 (32-bit) rather than 8 > > (64-bit)). Speculative on my part, but I ponder such when seeing code > > like somefunc(sizeof(int)). Absolute nonsense. pgp7EhexLK9bJ.pgp Description: PGP signature
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
Glen Barber wrote: Hello Kostik, On 8/27/10 2:58 PM, Kostik Belousov wrote: Of course. The new backtrace is here: http://gist.github.com/553734 I suspect that this was fixed in r210796/HEAD and r211138/RELENG_8. I will check this out on a test machine. Thanks. 2) Was the software rebuilt from source after the upgrade from i386 to amd64, or are you expecting the software to work without any hitches running on amd64 with lib32 (32-bit compatibility libaries)? The latter is not always possible/the case. clamav was rebuilt from ports. I previously went as far as downgrading to the previous version, to rule out something between 0.96.1 and 0.96.2; same results there. Was clamav rebuilt in the 32-bit jail ? At least your backtrace shows 32-bit image being executed. Yes, this is correct. Can you try it with original clamav 32-bit binary package? ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/Latest/clamav.tbz (or can you build your own on real 32-bit system instead of 32-bit jail on 64-bit host?) Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On 8/27/10 3:26 PM, Miroslav Lachman wrote: > Can you try it with original clamav 32-bit binary package? > ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/Latest/clamav.tbz > > (or can you build your own on real 32-bit system instead of 32-bit jail > on 64-bit host?) > I've tried that already, unfortunately. Same result. Regards, -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On 27/08/2010 20:53, Glen Barber wrote: On 8/27/10 3:26 PM, Miroslav Lachman wrote: Can you try it with original clamav 32-bit binary package? ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/Latest/clamav.tbz (or can you build your own on real 32-bit system instead of 32-bit jail on 64-bit host?) I've tried that already, unfortunately. Same result. Regards, you've tried this yeah? On 27/08/2010 12:39, Frank Wall wrote: Hi, I'm experiencing problems running ClamAV 0.96.2 on FreeBSD 7.1 (i386). The clamd will stop working immediately after startup. The process is still there, but unresponsive: i had something similar and eventually found that disabling JIT Bytecode compiler option, returned it to being stable. This only happened on one of my boxes though so i figured it was 'me'. Paul. -- - Paul Macdonald IFDNRG Ltd Web and video hosting - t: 0131 5548070 m: 07534206249 e: p...@ifdnrg.com w: http://www.ifdnrg.com - IFDNRG 40 Maritime Street Edinburgh EH6 6SA - ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On 8/27/10 5:03 PM, Paul Macdonald wrote: > On 27/08/2010 20:53, Glen Barber wrote: >> On 8/27/10 3:26 PM, Miroslav Lachman wrote: >>> Can you try it with original clamav 32-bit binary package? >>> ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/Latest/clamav.tbz >>> >>> >>> (or can you build your own on real 32-bit system instead of 32-bit jail >>> on 64-bit host?) >>> >> I've tried that already, unfortunately. Same result. >> >> Regards, >> > > On 27/08/2010 12:39, Frank Wall wrote: >> Hi, >> >> I'm experiencing problems running ClamAV 0.96.2 on FreeBSD 7.1 (i386). >> The clamd will stop working immediately after startup. The process >> is still there, but unresponsive: >> >> > > i had something similar and eventually found that disabling JIT > Bytecode compiler option, returned it to being stable. > This only happened on one of my boxes though so i figured it was 'me'. > > Paul. > > > you've tried this yeah? Yes. -- Glen Barber ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
