[Csync2] Format error while receiving data after segfault

[Vincent Régnard]

Vincent Régnard a écrit :
> Lars Ellenberg a écrit :
>> On Tue, Dec 09, 2008 at 10:42:36AM +0100, Vincent Régnard wrote:
>>> Hi all,
>>>
>>> With a large setup, resyncing from scratch after a -TIUX and doing a  
>>> full synchronisation afterward, csync2 process hangs up and crashes  
>>> sometimes client side, sometimes server side dumping a core. This 
>>> setup  was running fine before for smaller updates executed on a 
>>> regular basis.
>>>
>>> postmortem analysing core file with gdb says:
>>>
>>> Core was generated by `/usr/sbin/csync2 -ii -vvv'.
>>> Program terminated with signal 11, Segmentation fault
>>>
>>> With the exact same configuration a few weeks ago I ran this  
>>> synchronisation (10 hours run) but this ended normally, before 
>>> putting  the servers in production environement.
>>>
>>> I can imagine this is a memory related problem, I thing the systems 
>>> is  starting swapping at some point or something like this.
>>>
>>> How can I help debuging this problem ?
>>
>> if you have the core file already,
>> ask for a backtrace: bt
>>
>> if that does not look promissing, because of missing debug symbols,
>> rebuild csync2 with debug symbols enabled (add -g to the CFLAGS).
>> then reproduce, and capture the backtrace.
>>
> 
> I did that, and ran the freshly built byte sequence again, but problem 
> no more occur (probably incantations worked) !! But I realized the 
> memory was increasing a lot allong the synchronisation process (up to 
> 250MB for a single csync process), this looks abnormal.
> 
> Initial backtrace I have is useless (no symbols), I have the new binary 
> with debug symbols in the production environement now, I'll try to make 
> it segfault again and post the frame trace here.
> 

I am definately unable to reproduce the problem.

Maybe a clue: when I encountered the trouble, I actually reduced the 
backup-generation to 0 in the config file, was originaly 3. Reading the 
code very fast I guess this case may be not handled properly.

-- 
Vincent Régnard
vregnard at tbs-internet.com
TBS-internet.com
027 630 5902

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5793 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.linbit.com/pipermail/csync2/attachments/20081209/5d30dd1f/smime-0001.bin