... 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