Re: Squatter core dump

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

 



That is odd. I don't think we touched that part of the code for a long while. It might be that there is some other code corrupting the memory where SquatIndex is located.

Would you have a chance to run squatter with valgrind?

On Fri, May 7, 2021, at 3:23 PM, Gabriele Bulfon via Info wrote:
The problem lies here:

/* Add 'doc_ID' to the list of document IDs for word 'word_ptr'
   in the "all documents" trie. */
static int add_word_to_trie(SquatIndex * index, char const *word_ptr,
                            int doc_ID)
{
    WordDocEntry *word_entry = index->word_doc_allocator++;

    word_entry->doc_ID = doc_ID;
    add_to_table(index, word_ptr, SQUAT_WORD_SIZE - 1, word_entry);

    return SQUAT_OK;
}

Looks like word_entry (index->word_doc_allocator++) does not point to a valid memory area.
 
What may have happened?
Gabriele
 
 




Da: Gabriele Bulfon via Info <info@xxxxxxxxxxxxxxxxxx>
A: Info <info@xxxxxxxxxxxxxxxxxx>
Data: 7 maggio 2021 14.23.07 CEST
Oggetto: Squatter core dump
 
Hi,
 
I could set up a cloned machine with a specific big mailbox causing core dump every time squatter tries to rebuild the index.
So I rebuilt the squatter binary with debug info (-g) and here is the gdb back trace for 2.5.11 sources:
 
(gdb) bt
#0  0x00000000004067a7 in add_word_to_trie (index=0x652600, word_ptr=0xffffdf7fb949312d <error: Cannot access memory at address 0xffffdf7fb949312d>, doc_ID=28651) at imap/squat_build.c:790
#1  0x0000000000407ce1 in dump_index_trie_words (index=0x652600, first_char=191, result_offset=0xffffdf7fffdfdcfc) at imap/squat_build.c:1449
#2  0x0000000000408177 in index_close_internal (index=0x652600, OK=1) at imap/squat_build.c:1589
#3  0x00000000004085c8 in squat_index_finish (index=0x652600) at imap/squat_build.c:1695
#4  0x0000000000404d74 in squat_single (state=0x41ddc0, incremental=0) at imap/squatter.c:484
#5  0x0000000000405331 in index_me (name=0xffffdf7fffdfe920 "sonicle.com!user.test^big", matchlen=0, maycreate=0, rock=0xffffdf7fffdff924) at imap/squatter.c:636
#6  0x00000000004056ee in main (argc=7, argv=0xffffdf7fffdff968) at imap/squatter.c:746
 
I don't know if this is the same reason why cyrus.squat is always rebuilt from scratch on many big mailboxes.
Hope this may help close this long awaited resolution.
I can patch & rebuild binaries easily on this cloned test machine, if you can give me directions on where the problem may be.
 
Thanks!
Gabriele
 


[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