cyrus-murder problems with database corruption in the frontend/master

[João Assad]

João Assad wrote:

> Derrick J Brashear wrote:
>
>> On Fri, 8 Apr 2005, João Assad wrote:
>>
>>> João Assad wrote:
>>>
>>>> Managed to get a backtrace using debug_command ( thanks for this 
>>>> nifty feature Henrique de Moraes )
>>>
>>>
>>>
>>> 2 gdb backtraces from the production server.
>>
>>
>>
>> curiously, the strace output isn't showing an mmap() call fail, that 
>> I see, before the error shows up.
>>
> Yeah I noticed that too. thats because strace attached to the main 
> thread and is not tracing threads forked by it.
> Im doing some tests using strace -ff now , to follow all forked 
> threads and I see the mmaps there... but it makes cyrus too slow
> and thats causing all sorts of weird behaving on futex
>
> futex(0x8101c64, FUTEX_WAIT, 772, {59, 999828000}) = -1 ETIMEDOUT 
> (Connection timed out)
> futex(0x8101c60, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource 
> temporarily unavailable)
>
>
I could do a strace -f wich would dump all the traces from all the 
threads into a single file... but its a nightmare to read it.
by reading some strace output here I've noticed mmaps complaining about 
ENOMEM way before the mmap inside map_refresh goes crazy.
then It came to me that cyrus only do mmap inside map_refresh and It 
seemed to me that it was tcp_wrappers mmap that was causing the rist ENOMEM

Im trying to recompile without tcp_wrappers and check if I can clean 
strace output a bit.

---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html