Re: Solved: Squatter core dump

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm not building from a git clone of the tag, but downloading the tar gz from here:
 
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.4.1/cyrus-imapd-3.4.1.tar.gz
 
Do you mean this archive may have "-s" disabled?
 
 
Sonicle S.r.l. http://www.sonicle.com
Music: http://www.gabrielebulfon.com
eXoplanets : https://gabrielebulfon.bandcamp.com/album/exoplanets
 
 



Da: Robert Stepanek <rsto@xxxxxxxxxxxxxxxx>
A: Gabriele Bulfon <gbulfon@xxxxxxxxxxx>Gabriele Bulfon via Info <info@xxxxxxxxxxxxxxxxxx>
Data: 17 maggio 2021 13.56.53 CEST
Oggetto: Re: Solved: Squatter core dump


Hi Gabriele,
 
On Fri, May 14, 2021, at 5:11 PM, Gabriele Bulfon wrote:
I've found that upgrading to Cyrus 3.4.1, squatter works fine on my cloned imap base!
Now I will do more tests and check again the xapian backend.
 
Great!
 
This version of squatter misses the "-s" option, so I have no way to tell it to not consider unchanged mailboxes.
 
I just checked out the 3.4.1 tag from Github and it does contain the -s option: https://github.com/cyrusimap/cyrus-imapd/blob/81629293ca4ced90bde67bc488e7c26537735adb/imap/squatter.c#L140
 
I just pushed a Cassandane test that confirms this: https://github.com/cyrusimap/cassandane/commit/5a35100aab443c807607c1c9cb91249541dd4662
 
Cheers,
Robert
 
This is important on my ZFS based servers, where rewriting the entire cyrus.squat when nothing has changed will cause a useless lot of space used by zfs snapshots.
Why is this "-s" option now available only on master branch?
 
Thanks a lot,
Gabriele
 
 

 
 
Da: Robert Stepanek <rsto@xxxxxxxxxxxxxxxx>
A: Gabriele Bulfon <gbulfon@xxxxxxxxxxx>Gabriele Bulfon via Info <info@xxxxxxxxxxxxxxxxxx>
Data: 11 maggio 2021 13.54.40 CEST
Oggetto: Re: Squatter core dump
Yes, but unfortunately I didn't find time to do more than that. The log pretty much confirms that there's memory corruption, with invalid reads and writes all over the place.
 
This line looks like a potential start to debug:
 
==17293==  Address 0xff28149a0 is 0 bytes inside a block of size 2,056 free'd
==17293==    at 0xFFFF64A29: free (vg_replace_malloc.c:549)
==17293==    by 0x407A28: write_trie_word_data (squat_build.c:1364)
 
(interestingly, in my code the free happens at line 1363).
 
As a very crude attempt, you could just comment out this free() call. It will leak memory, but if that omits the segfault then we have narrowed down what's causing the corruption.
 
On Tue, May 11, 2021, at 1:38 PM, Gabriele Bulfon wrote:
Hight, did you have any chance to check the valgrind log I've sent?
 
 

 
 
Da: Robert Stepanek <rsto@xxxxxxxxxxxxxxxx>
A: Gabriele Bulfon via Info <info@xxxxxxxxxxxxxxxxxx>
Data: 7 maggio 2021 17.45.19 CEST
Oggetto: Re: Squatter core dump
On Fri, May 7, 2021, at 5:31 PM, Gabriele Bulfon via Info wrote:
Never did, it's our illumos distro, but I may have valgrind.
Can you help on this?
 
Just running "valgrind --leak-check=full <path-to-squatter> <your-args>" should do the trick.
 
Cheers,
Robert
 
 

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux