Re: Solved: Squatter core dump

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 <[email protected]>
A: Gabriele Bulfon <[email protected]>Gabriele Bulfon via Info <[email protected]>
Data: 17 maggio 2021 13.56.53 CEST
Oggetto: Re: Solved: Squatter core dump



p.MsoNormal,p.MsoNoSpacing{margin:0}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
 
 
Sonicle S.r.l. : http://www.sonicle.com
Music: http://www.gabrielebulfon.com
eXoplanets : https://gabrielebulfon.bandcamp.com/album/exoplanets
 

 

 
 
Da: Robert Stepanek <[email protected]>
A: Gabriele Bulfon <[email protected]>Gabriele Bulfon via Info <[email protected]>
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?
 
 
Sonicle S.r.l. : http://www.sonicle.com
Music: http://www.gabrielebulfon.com
eXoplanets : https://gabrielebulfon.bandcamp.com/album/exoplanets
 

 

 
 
Da: Robert Stepanek <[email protected]>
A: Gabriele Bulfon via Info <[email protected]>
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
 
 
Cyrus / Info / see discussions + participants + delivery options Permalink

------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/T290da80a662e5a08-M09c91cfab1b59daf72d04eb7
Delivery options: https://cyrus.topicbox.com/groups/info/subscription