FreeBSD support

[zilog]

Hallo,
uff, never more . but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:

http://public.avast.com/~cimbal/freebsdalpha

NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000   sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.

NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).

regards,
pc

Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near

i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).

Hi,

Thank you for your effort.  The program seems runs fine......  Just one glitch in the installtion.... The installation script will change the permission of /tmp to 0700, which cause many other programs panic, and also have some difficulties setting up the cron job.   Please see the error message for cron job below.

Code: [Select]

Installer will insert call for virus database update to the crontab now.
This task can be done by avastvpsupdate.sh or avastvpsupdate.pl.
Installer will check which way is suitable for you, and also will try
to download the latest database version. This step might take up to few
minutes under some circumstances, but can be interrupted anytime by
pressing Ctrl-C (in this case, add the line to the crontab manually
and probably fix the problem in /etc/avastvpsupdate.conf).
chmod: 3-03-09-15-32-23-77557: No such file or directory
crontab: no crontab for root


Thanks for report, William XP, we'll fix those "minor" problems too.

btw. NOTE 3 - "freebsd4" and "freebsd5" have "auxiliary stack" feature built-in (yes, default spacing between threads is 128kB for libc_r and even 64kB/69kB for 5.3's threading libraries), but "freebsd6" doesn't use this (it seems that the spacing is reasonable enough for freebsd6.x and 7.x - 1MB).

regards,
pc

[williamXP]

Hallo,
uff, never more . but, with some help of desperate modifications in hexedit, and few nasty hacks, here it is:

http://public.avast.com/~cimbal/freebsdalpha

NOTE: first, change the shm limits (installer will check this & warn you, but anyway): sysctl -w kern.ipc.shmmax=64000000   sysctl -w kern.ipc.shmall=16384 . then, run the mkinstall of libavastengine, then mkinstall of avast4server. default limits are too smal to acomodate present runtime vps.

NOTE2: the BSD-release numbering is rather misnomer (because, the main changes in bsd binary compatibility aren't bound to major releases - so 4 is just libc_r-style, 5 is for libpthread/libkse style, and 6 is libthr-style, in the fact).

regards,
pc

Latest FreeBSD distros (4,5,6,7 - particular releases) absolutely redefine the meaning of "binary incompatibility" and "library hell" terms to new horizons. it's hard to point on hardly one distributions where's everything in order and is working without bugs and oddities, or at least is buggy in the same manner as the previous version, to be able to create a workaround.. It seems to be the most problematic platform for third-party binary distributing far and near

i'll tidy thing up tomorow (freebsd5 has problems on 6.0s, although the libs are interface-compatible - strange. lock recursion is reutrned (but there's no such recursion, proven elsewhere), the process gets killed but non-shm build works fine, with the same pthreading decorations - so, another nightmare).

Hi,

Thank you for your effort.  The program seems runs fine......  Just one glitch in the installtion.... The installation script will change the permission of /tmp to 0700, which cause many other programs panic, and also have some difficulties setting up the cron job.   Please see the error message for cron job below.

Code: [Select]

Installer will insert call for virus database update to the crontab now.
This task can be done by avastvpsupdate.sh or avastvpsupdate.pl.
Installer will check which way is suitable for you, and also will try
to download the latest database version. This step might take up to few
minutes under some circumstances, but can be interrupted anytime by
pressing Ctrl-C (in this case, add the line to the crontab manually
and probably fix the problem in /etc/avastvpsupdate.conf).
chmod: 3-03-09-15-32-23-77557: No such file or directory
crontab: no crontab for root


Thanks for report, William XP, we'll fix those "minor" problems too.

btw. NOTE 3 - "freebsd4" and "freebsd5" have "auxiliary stack" feature built-in (yes, default spacing between threads is 128kB for libc_r and even 64kB/69kB for 5.3's threading libraries), but "freebsd6" doesn't use this (it seems that the spacing is reasonable enough for freebsd6.x and 7.x - 1MB).

regards,
pc

Hi zilog,

some more report...

I can't get the program running in amavisd..  it will complain...

Code: [Select]

Mar  6 15:53:32 ns amavis[78761]: (78761-01) (!!)run_av (avast! Antivirus) FAILED - unexpected exit 22, output="avastcmd: can not initialize avast! engine: VPS file was destroyed"
Mar  6 15:53:32 ns amavis[78761]: (78761-01) (!!)avast! Antivirus av-scanner FAILED: /usr/local/bin/avastcmd unexpected exit 22, output="avastcmd: can not initialize avast! engine: VPS file was destroyed" at (eval 117) line 527.

my av setting is amavisd.conf is  (i install Avast with --prefix=/usr/local )

Code: [Select]

  ### http://www.avast.com/
  ['avast! Antivirus', ['/usr/local/bin/avastcmd','avastcmd'],
    '-a -i -n -t=A {}', [0], [1], qr/\binfected by:\s+([^ \t\n\[\]]+)/ ],

However, I can manually run avastcmd to scan (but the scan speed is slow)

for example, this scan took about 4 seconds before I can see the statistic report.

Code: [Select]

#avastcmd License.dat   
/var/lib/avast4/License.dat     [OK]
#
# Statistics:
#
# scanned files:        1
# scanned directories:  0
# infected files:       0
# total file size:      1.3 kB
# virus database:       090305-1 05.03.2009
# test elapsed:         0s 2ms
Any ideas?

[zilog]

hmhm,
the "tmp chmod-ded to 700" problem isn't reproducible here - could you give us more details? (version of your system, installation log)...

hint - spawn sh, and run install this way:

./mkinstall.sh 2>&1 | tee inst.log

... and copy/paste the log here, thanks in advance.

regards,
pc

[williamXP]

hmhm,
the "tmp chmod-ded to 700" problem isn't reproducible here - could you give us more details? (version of your system, installation log)...

hint - spawn sh, and run install this way:

./mkinstall.sh 2>&1 | tee inst.log

... and copy/paste the log here, thanks in advance.

regards,
pc

Hi zilog,

I believe this variable was the root cause --  "PSH_UNIQUE=`date +%h-%m-%y-%H-%M-%S`-$$"
It generated a filename with a space in front of it, which cause the following command (ie. chmod, md5) to fail.  After I changed it to "`date +%d-%m-%y-%H-%M-%S`-$$" , the problem went away.

As for the amavisd problem, I figured out that my amavisd didn't have appropriate permission to access /var/lib.  After I change the permission, it runs fine now. (although it is still slow to manually run avastcmd)

Thanks.

[zilog]

Hallo,

please note that the (present) runtime vps takes ~50MB. because it is (and must be - security reasons) user-separated, this amount is taken for each user. And, sections in avastd allow defining "users". Thus, more user sections -> more memory needed.

avastcmd is a standalone app, and creates the runtime once (or takes it from SHM, when it founds it's already up and usable), but again, it's per-uid thing.

Thus, sysctl -w kern.ipc.shmmax=256000000; sysctl -w kern.ipc.shmall=65536 - and avast would load the runtime VPS fine (hopefully).

regards,
pc

[williamXP]

Hallo,

please note that the (present) runtime vps takes ~50MB. because it is (and must be - security reasons) user-separated, this amount is taken for each user. And, sections in avastd allow defining "users". Thus, more user sections -> more memory needed.

avastcmd is a standalone app, and creates the runtime once (or takes it from SHM, when it founds it's already up and usable), but again, it's per-uid thing.

Thus, sysctl -w kern.ipc.shmmax=256000000; sysctl -w kern.ipc.shmall=65536 - and avast would load the runtime VPS fine (hopefully).

regards,
pc

Another problem... this time it is avastd...

The daemon could start successfully, however, when I try to run avastlite, it will hang forever.  In addition, when I issued a shutdown flag (kill -TERM) to the daemon process, its child processes won't die.  I have to use kill -9 to remove them.  The /var/log/avast4/avastd.log did not report any errors.

here is my configuration...

avastd.rc

Code: [Select]

# Copyright(C) 2005-2007 ALWIL Software
# Config file for /etc/init.d/avastd
#
# Note: this is NOT the main avastd configuration file. That is in
# /etc/avastd.conf file. This merely sets startup options for the
# avastd initscript.

# Command to be executed before the daemon is started
#AVASTD_PRECOMMAND=""

# Command to be executed after the daemon is stopped
#AVASTD_POSTCOMMAND=""

# For information on avastd options, see "avastd -h"
AVASTDCONF="/usr/local/etc/avastd.conf"
#AVASTDOPTS="$AVASTDOPTS -c ${AVASTDCONF}"
avastd.conf

Code: [Select]

#There are two types of sections - the special [global] section and up
#to five user-defined scanner sections.

#Global section:
[global]
   # use system logger to log messages instead of logging into a file
   # disabled by default
   usesyslog = no

   # specify syslog facility when syslog logging is enabled
   # please refer to syslog(3) manual page (part with facility
   # argument parameters) to list all possible values
   # default is LOG_DAEMON
   syslogfacility = LOG_DAEMON

   # specify location of a logging file
   # default log file is /var/log/avast4/avastd.log
   # NOTE: if you want to log to file, disable 'usesyslog' option
   logfile = /var/log/avast4/avastd.log

   # controls the maximum size (in bytes) of each log file before it's
   # rotated. It's functional only if the file logging is enabled
   # set to 0 to disable log rotating (default).
   maxlogfile=200000000
   #200MB

   # don't log informational messages (LOG_INFO priority)
   # this option allows to disable logging of informational messages
   # when a new connection is established/closed
   # disabled by default
   ignoreloginfo=0

#Scanner sections:
#The section name is the name of scanning service and the parameters
#within the section defines its attributes. The name is user-defined
#and can also be used as a base for the socket file name of the daemon
#located in /var/run/avast4 directory, when there's no interface value
#set.
[local]
   # defult number of pre-forked daemons to be launched at start
   # a value of 0 disables the daemon (default is 3, maximum is 25)
   daemoncount = 5

   # this option defines maximum count of forked avastd daemons
   # new avastd daemon is forked to accept a new connection, when the
   # others are occupied and it will be automatically killed after
   # 3 minutes of inactivity
   # (default is 25)
   maxdaemoncount = 15

   # bind daemons to specific local (Unix) file socket or IP address
   # NOTE: please use firewall to restrict connections when binding
   # to public IP address
   #listen = 127.0.0.1:5036
   #listen = /var/run/avast4/mailscanner.sock
   #listen = 127.0.0.1:5037
   #listen = /var/run/avast4/filescanner.sock
   listen = /var/run/avast4/local.sock

   # connection timeout in seconds
   # idle connection will be automatically closed after elapsing the
   # period (default is infinite)
   timeout = 300

   # environment of forked daemons :
   # user name used at runtime
   # the value sets the user and user's permissions of the local
   # (Unix) socket file if enabled (see 'listen' option)
   # the value can be a username or a numeric UID
   user = root
   # group name used at runtime
   # the value sets the group and group's permissions of the local
   # (Unix) socket file if enabled (see 'listen' option)
   # the value can be a groupname or a numeric GID
   ;group = root
   # setting this option enables to chroot forked daemon into
   # specific directory - jail (disabled by default).
   # NOTE: the directory tree must also include daemons's 400.vps file
   ;rootdir = /var

   # general settings of the virus scan engine:

   # avast! antivirus engine paths :
   # NOTE: these options modify values in /etc/avastengine.conf file
   # data directory of the avast! engine, the directory must include
   # the virus signature file (400.vps)
   # the directory must be located in 'rootdir' tree (if specified)
   datadir = /var/lib/avast4

   # avast! engine temporary directory, the directory is used to
   # temporary unpack archived files (must be writeable)
   # the directory must be located in 'rootdir' tree (if specified)
   tempdir = /var/lib/avast/tmp

   # full path to avast! engine license file
   # the file must be located in 'rootdir' tree (if specified)
   licensefile = /var/lib/avast4/License.dat

   # scanner working area:
   # working directory of the daemon, files outside of the directory
   # will be excluded from scanning
   # the directory must be located in 'rootdir' tree (if specified)
   ;workdir = /var

   # enable scanning in subdirectories (default is false)
   subdirs = true

   # directory in the working tree which will be excluded from
   # scanning
   # you can set multiple directories as a colon separated list or
   # each directory in a separate line (maximum is 30 paths)
   # directories must be located in 'rootdir' tree (if specified)
   # empty list by default
   ;excludedir = /var/excludedir1:/var/exludedir2

   # scanner flags :
   # test all files (default is 1)
   # tells avast whether you want to test all files (1) or just some
   # of them, it is recommended always set this flag to 1 for
   # Linux/Unix environment
   testall = 1
   # scan entire files (default is 0)
   # if 0, only parts of the files will be scanned, setting 1 can be
   # very slow for huge files
   testfull = 0
   # ignore virus sets (default is 0)
   # setting to 1 means that all types of viruses will be scanned in
   # all objects (and not selectively, which is the case if this
   # option is set to 0).
   ignoretype = 0

   # scanner packers :
   # scan inside compressed files, avast! antivirus kernel enables
   # scanning of these compression formats:
   # Z = ZIP(default), G = GZIP(default), B = BZIP2(default),
   # T = TAR(default), I = MIME, J = ARJ, R = RAR, X = Exec(default),
   # O = ZOO, Q = ARC, H = LHA, F = TNEF, V = CPIO, K = CHM, P = RPM,
   # Y = ISO, D = DBX, 6 = SIS, U = OLE(default), 1 = INSTALL(default),
   # W = WINEXEC(default), A = All, N = None
   ;archivetype = ZGBTXU1W
   archivetype = A

   # don't list all archived files and summary all to one scan result
   # this reports, whether an archive is infected, contains encrypted
   # files or files that cannot be scanned or all files are clean
   # disabled by default
   summaryarchive = 0

   # maximum recurse level in packed files
   # 0 means default value of 32 (maximum is 128)
   maxpackerdepth = 0

   # determine packer bomb :
   # If you do not declare variables, default values will be used.
   # Using 0 values, decompression bomb checking will be disabled.
   #
   #   The maximum size of the file extracted from an archive. If the
   #   file in the archive exceeds the value it will be skipped.
   #   Note: a message with such a file will be treated as a mail bomb.
   #   Default is 500MB.
   maxfilesizetoextract = 500000
   #   Maximum compression ratio, i.e., the ratio of the unpacked file
   #   length to the length of the packed file in the archive. If the
   #   ratio exceeds the value, the file will not be extracted and
   #   therefore will not be checked.
   #   Default is 1:50.
   maxcompressionratio = 50
   #   Maximum file size inside archive, beginning from which the
   #   maximum compression ratio will be checked (if enabled by
   #   maxcompressionratio parameter).
   #   Default is 10MB.
   compressioncheckthreshold = 10000
   #   Maximum "total" compression ratio of the real archive
   #   Default is 1:100
   maxtotalcompressionratio = 100
   #   Number of files inside of an archive (from all packed depths),
   #   beginning from which the maximum total compression ratio will
   #   be checked.
   #   Default is 1000.
   totalcompressioncheckthreshold = 1000

   # log scan results level :
   # Default is logging infected files and error scan results.
   loginfected = 1
   logerrors = 1
   logclean = 1



[zilog]

Hallo,

please, check whether there are the SHM blocks when avastd runs (ipcs -a). The kern.ipc.XXX stuff must somehow reflect the capabilities (phys. mem. amount) of your machine, thus thus you must put in reasonable values.

With improper values, the SHM layer might get into unusable state (and that's also why we don't set this in installer, even when we know that the limits aren't suficient - it's peril). There's a small utility "shmprobe", in the install-tree, useful for quick checking.

btw. avastcmd is faster, when the SHM blocks are already there. Try to spawn one (avastcmd /usr), ctrl-z it, and then spawn another one. The initial delay won't happen.

regards,
pc

[zilog]

Hallo,

please, check whether there are the SHM blocks when avastd runs (ipcs -a). The kern.ipc.XXX stuff must somehow reflect the capabilities (phys. mem. amount) of your machine, thus thus you must put in reasonable values.

With improper values, the SHM layer might get into unusable state (and that's also why we don't set this in installer, even when we know that the limits aren't suficient - it's peril). There's a small utility "shmprobe", in the install-tree, useful for quick checking.

btw. avastcmd is faster, when the SHM blocks are already there. Try to spawn one (avastcmd /usr), ctrl-z it, and then spawn another one. The initial delay won't happen.

regards,
pc

... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.

regards,
pc

[williamXP]

... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.

regards,
pc

It does not work ......  However, it seems that 'avastcmd' runs pretty well for the past few days.  We will just keep it running this way for now.....  Thanks a lot.

[zilog]

... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.

regards,
pc

It does not work ......  However, it seems that 'avastcmd' runs pretty well for the past few days.  We will just keep it running this way for now.....  Thanks a lot.

i'll have to analyse the avastd's lock-up anyway, on Monday.

regards,
pc

[zilog]

... just small add-on note - i managed to reproduce the flaw on our machines too, thus we can analyse it on Monday. Btw. could you try to limit the avastd.conf to only one section with only one worker? Maybe this will help (maybe not), but might be useful for localising the cause of the flaw.

regards,
pc

It does not work ......  However, it seems that 'avastcmd' runs pretty well for the past few days.  We will just keep it running this way for now.....  Thanks a lot.

i'll have to analyse the avastd's lock-up anyway, on Monday.

regards,
pc

Hmmm.... some, let's say, "progress" or "conclusion".
After _many_ hours with testing, the conclusion is, that for some obscure reason, after setting the SIGINT sigaction handler, the underlying threading layer in libthr gets somehow harmed, and later, any pthread_condvar operation will be in the first step fully nonsensually refused with -EPERM (although the lock is brand new, just initialised, and for sure belongs to the thread who's requesting the op). In turn, re-acquiring the variable will succeed, but the lock acqired this way will be never dropped as it ought to be, inside the waiting function, with a deadlock as consequence.

Even more interesting - in a bare testing app, the sigint hooking _doesn't_ trigger this suspicious behavior. Strange enough. Similar nightmare was solved some months ago on Solaris, where their threading library deliberately used the same SIGALRM timing source, as the system's sleep()- causing spurious unvanted signaling to occur.

So, I decided, at least for now, to emulate these lame pthread_conditionals with busy waiting with reasonable poll-delay.
Let's test the packages: http://public.avast.com/~cimbal/BSD6/

regards,
pc

[zilog]

Btw. the ill-famed FreeBSD threading-library ping-pong really rulez - unbelievable.

s threa/76690 threads fork hang in child for -lc_r

1 problem total.

Serious problems

S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o
s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL
s bin/32295 threads pthread dont dequeue signals
s threa/34536 threads accept() blocks other threads
s threa/39922 threads [threads] [patch] Threaded applications executed with
s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under
s threa/49087 threads Signals lost in programs linked with libc_r
o threa/70975 threads unexpected and unreliable behaviour when using SYSV se
o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST
o threa/75273 threads FBSD 5.3 libpthread (KSE) bug
o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag
s threa/76694 threads fork cause hang in dup()/close() function in child (-l
o threa/79683 threads svctcp_create() fails if multiple threads call at the
o threa/80435 threads panic on high loads
o threa/83914 threads [libc] popen() doesn't work in static threaded program
s threa/84483 threads problems with devel/nspr and -lc_r on 4.x
s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc
s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r
o threa/101323 threads fork(2) in threaded programs broken.
o threa/103975 threads Implicit loading/unloading of libpthread.so may crash
o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat
o threa/118715 threads kse problem
o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7
o threa/121343 threads pthread_cond_wait hanging in libthr

24 problems total.

Non-critical problems

S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/30464 threads pthread mutex attributes -- pshared
s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra
s threa/40671 threads pthread_cancel doesn't remove thread from condition qu
s threa/69020 threads pthreads library leaks _gc_mutex
o threa/79887 threads [patch] freopen() isn't thread-safe
o threa/80992 threads abort() sometimes not caught by gdb depending on threa
o threa/110306 threads apache 2.0 segmentation violation when calling gethost
o threa/115211 threads pthread_atfork misbehaves in initial thread
o threa/116181 threads /dev/io-related io access permissions are not propagat
o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP

10 problems total.

[goodmanbeats]

Hello again,

Had time now to look around Avast again... Now on a FreeBSD 6.2 box. The latest packages You linked are installed, avastcmd runs fine, but avastd does not start... it simply exits no matter what options are given to it. shm sysctls set to higher values than default. Any idea?

Update: my demo license expired... well, this was only written in the /var/log/avast4/avastd.log, tho there was a /var/lib/avast4/log folder and I was looking there, or at least expecting a message on command line like "License expired". I'll test with another demo license for some days, if we are running fine, we'll purchase

Daniel

[williamXP]

Btw. the ill-famed FreeBSD threading-library ping-pong really rulez - unbelievable.

s threa/76690 threads fork hang in child for -lc_r

1 problem total.

Serious problems

S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o
s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL
s bin/32295 threads pthread dont dequeue signals
s threa/34536 threads accept() blocks other threads
s threa/39922 threads [threads] [patch] Threaded applications executed with
s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under
s threa/49087 threads Signals lost in programs linked with libc_r
o threa/70975 threads unexpected and unreliable behaviour when using SYSV se
o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST
o threa/75273 threads FBSD 5.3 libpthread (KSE) bug
o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag
s threa/76694 threads fork cause hang in dup()/close() function in child (-l
o threa/79683 threads svctcp_create() fails if multiple threads call at the
o threa/80435 threads panic on high loads
o threa/83914 threads [libc] popen() doesn't work in static threaded program
s threa/84483 threads problems with devel/nspr and -lc_r on 4.x
s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc
s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r
o threa/101323 threads fork(2) in threaded programs broken.
o threa/103975 threads Implicit loading/unloading of libpthread.so may crash
o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat
o threa/118715 threads kse problem
o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7
o threa/121343 threads pthread_cond_wait hanging in libthr

24 problems total.

Non-critical problems

S Tracker Resp. Description
--------------------------------------------------------------------------------
s threa/30464 threads pthread mutex attributes -- pshared
s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra
s threa/40671 threads pthread_cancel doesn't remove thread from condition qu
s threa/69020 threads pthreads library leaks _gc_mutex
o threa/79887 threads [patch] freopen() isn't thread-safe
o threa/80992 threads abort() sometimes not caught by gdb depending on threa
o threa/110306 threads apache 2.0 segmentation violation when calling gethost
o threa/115211 threads pthread_atfork misbehaves in initial thread
o threa/116181 threads /dev/io-related io access permissions are not propagat
o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP

10 problems total.

Hi,

I just want to suggest that you post some more technical details to the FreeBSD mailing list.  Perhaps somebody there will know a better way to get around these problem.  We have purchased Avast for our company, and it has stopped lots of malicious emails (much better than ClamAV .....).  Thanks for your work.


 

[zilog]

> Hi,
> I just want to suggest that you post some more technical details to the FreeBSD mailing list.  Perhaps somebody there will know

Hallo, it was taken from the developer forum (i was verifying whether someone else faced the same behavior). There are only 2 ways, what to do  - waiting for newer, hopefully less crippled release, or using some independent workaround...

regards,
pc