On 06/30/2011 07:59 PM, Michael Scheidell wrote:
>
>
> On 6/30/11 7:35 AM, Török Edwin wrote:
>> So the bug is that pthread_cond_timedwait's timeout parameter became invalid.
>>
>> The patch above does 2 things:
>> - if pthread_cond_timedwait returns any error (other than ETIMEDOUT) it
>> logs
On 6/30/11 7:35 AM, Török Edwin wrote:
So the bug is that pthread_cond_timedwait's timeout parameter became invalid.
The patch above does 2 things:
- if pthread_cond_timedwait returns any error (other than ETIMEDOUT) it logs
it, and breaks the loop
- make sure pthread_cond_timedwait's tim
On 06/30/2011 07:18 PM, Antoine Preteux wrote:
> Hello,
>
> One of our customer has an issue which could be linked to the problem explain
> in the thread Av Timeout.
>
> Version 0.97 self compiled on Linux/Etch.
This is a different problem, the problem in the Av Timeout thread is specific
to c
Hello,
One of our customer has an issue which could be linked to the problem
explain in the thread Av Timeout.
Version 0.97 self compiled on Linux/Etch.
Config.log here : http://dl.free.fr/lPN1ukvMf
We mostly use clamd as a gateway AV (squid+icap)
We caught a core dump and you can get it her
On 6/30/11 7:35 AM, Török Edwin wrote:
died already
I couldn't get the bytecode_watchdog to crash on Linux/amd64,
Applying the patch now.
not sure it has anything to do with amd64, had someone with linux/i386
report it also.
I think it is volume, race condition, something.
The first system
On 06/29/2011 10:53 PM, Michael Scheidell wrote:
>
>
> On 6/29/11 3:29 PM, Török Edwin wrote:
>> (gdb) backtrace full
> (gdb) backtrace full
> #0 0x0008018baf4a in __error () from /lib/libthr.so.3
> No symbol table info available.
> #1 0x0008018bac3b in __error () from /lib/libthr.so.3