Bug 3943 - 3.16.0 crashes with config from 3.15.1 and older
Summary: 3.16.0 crashes with config from 3.15.1 and older
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: Folders (show other bugs)
Version: 3.16.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-01-06 14:26 CET by Michael Schwendt
Modified: 2018-09-12 12:39 CEST (History)
0 users

See Also:


Attachments
claws-mail --debug output with #mh/Mailbox messages removed (13.35 KB, text/plain)
2018-01-11 00:46 CET, Michael Schwendt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Schwendt 2018-01-06 14:26:15 CET
I've posted about this to the mailing-list without receiving any response:
http://lists.claws-mail.org/pipermail/users/2017-December/020541.html

An upgrade to Claws Mail 3.16.0 crashes early for me with a configuration
that works fine with 3.15.1 and older. When downgrading to 3.15.1, that one
still works. Environment is Fedora 27 x86_64.

I've rebuilt the folder tree in 3.15.1, but that doesn't help either.

Thread 5 (Thread 0x7fffde536700 (LWP 29672)):
#0  0x00007ffff2c760d9 in syscall () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff35fb66a in g_cond_wait_until () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff358a381 in g_async_queue_pop_intern_unlocked ()
   from /lib64/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff35dde64 in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#4  0x00007ffff35dd4c6 in g_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff4585609 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6  0x00007ffff2c7be6f in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 4 (Thread 0x7fffded37700 (LWP 29671)):
#0  0x00007ffff2c760d9 in syscall () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff35fb66a in g_cond_wait_until () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff358a381 in g_async_queue_pop_intern_unlocked ()
   from /lib64/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff35dde64 in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#4  0x00007ffff35dd4c6 in g_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff4585609 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6  0x00007ffff2c7be6f in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 3 (Thread 0x7fffdf538700 (LWP 29670)):
#0  0x00007ffff2c6f8bb in poll () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff35b5ed9 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff35b6272 in g_main_loop_run () from /lib64/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff6005b36 in gdbus_shared_thread_func () from /lib64/libgio-2.0.so.0
No symbol table info available.
#4  0x00007ffff35dd4c6 in g_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff4585609 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6  0x00007ffff2c7be6f in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 2 (Thread 0x7fffdfd39700 (LWP 29669)):
#0  0x00007ffff2c6f8bb in poll () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff35b5ed9 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff35b5fec in g_main_context_iteration () from /lib64/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff35b6031 in glib_worker_main () from /lib64/libglib-2.0.so.0
No symbol table info available.
#4  0x00007ffff35dd4c6 in g_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff4585609 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6  0x00007ffff2c7be6f in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 1 (Thread 0x7ffff7faff80 (LWP 29665)):
#0  0x00007ffff2ce5988 in __strchr_avx2 () from /lib64/libc.so.6
No symbol table info available.
#1  0x0000555555834ad6 in make_dir_hier (dir=dir@entry=0x0) at utils.c:2186
        parent_dir = <optimized out>
        p = <optimized out>
#2  0x00005555556e3d6a in imap_get_num_list (folder=0x555556149600, 
    _item=0x55555619f290, msgnum_list=0x7fffffff6620, old_uids_valid=0x7fffffff661c)
    at imap.c:4596
        item = 0x55555619f290
        session = <optimized out>
        uidlist = 0x0
        dir = <optimized out>
        known_list_len = <optimized out>
        path = 0x0
        __func__ = "imap_get_num_list"
#3  0x00005555556c85ec in folder_item_scan_full (item=item@entry=0x55555619f290, 
    filtering=filtering@entry=1) at folder.c:2161
        folder = 0x555556149600
        folder_list = 0x0
        cache_list = 0x0
        folder_list_cur = <optimized out>
        cache_list_cur = <optimized out>
        new_list = 0x0
        exists_list = 0x0
        elem = <optimized out>
        newmsg_list = 0x0
        newcnt = 0
        unreadcnt = 0
        totalcnt = 0
        markedcnt = 0
        unreadmarkedcnt = 0
        repliedcnt = 0
        forwardedcnt = 0
        lockedcnt = 0
        ignoredcnt = 0
        watchedcnt = 0
        cache_max_num = <optimized out>
        folder_max_num = <optimized out>
        cache_cur_num = <optimized out>
        folder_cur_num = <optimized out>
        update_flags = 0
        old_uids_valid = 1
        subject_table = 0x0
#4  0x00005555556c96cb in folder_item_read_cache (item=item@entry=0x55555619f290)
    at folder.c:2662
        unreadcnt = 0
        unreadmarkedcnt = 0
        lockedcnt = 0
        msginfo = <optimized out>
        cur = <optimized out>
        markedcnt = 0
        repliedcnt = 0
        watchedcnt = 0
        newcnt = 0
        forwardedcnt = 0
        ignoredcnt = 0
        cache_file = 0x0
        mark_file = 0x0
        tags_file = 0x7fffd0008950 "/home/ms27/.claws-mail/tagsdb/#imap/GMX/Queue/.claws_tags"
        start = {tv_sec = 1514150424, tv_usec = 560996}
        end = {tv_sec = 93825004145152, tv_usec = 93825000506352}
        diff = <optimized out>
        timing_name = 0x555555942dd5 ""
        __FUNCTION__ = "folder_item_read_cache"
#5  0x00005555556c9e78 in folder_item_get_msg_list (item=0x55555619f290)
    at folder.c:2823
No locals.
#6  0x00005555556d3138 in folderview_update_node (folderview=<optimized out>, 
    node=<optimized out>) at folderview.c:1698
        ctree = <optimized out>
        style = <optimized out>
        color_style = <optimized out>
        item = <optimized out>
        xpm = <optimized out>
        openxpm = <optimized out>
        searchicon = 0x0
        mark = <optimized out>
        name = <optimized out>
        str = <optimized out>
        add_unread_mark = <optimized out>
        add_sub_match_mark = <optimized out>
        use_bold = <optimized out>
        use_color = <optimized out>
        col_pos = <optimized out>
        stype = <optimized out>
#7  0x00005555556d3837 in folderview_gnode_func (ctree=<optimized out>, 
    depth=<optimized out>, gnode=<optimized out>, cnode=<optimized out>, 
    data=<optimized out>) at folderview.c:1823
        folderview = <optimized out>
        item = <optimized out>
#8  0x000055555587e146 in gtk_sctree_insert_gnode (ctree=ctree@entry=0x555555d383f0, 
    parent=parent@entry=0x5555561a8d40, sibling=sibling@entry=0x5555561a8da0, 
    gnode=gnode@entry=0x55555618fef0, 
    func=func@entry=0x5555556d3810 <folderview_gnode_func>, 
    data=data@entry=0x555555f6de00) at gtksctree.c:1924
        clist = 0x555555d383f0
        cnode = 0x5555561a9a00
        child = 0x0
        new_child = <optimized out>
        list = 0x5555561a9a00
        work = <optimized out>
        depth = 2
#9  0x000055555587e1e4 in gtk_sctree_insert_gnode (ctree=0x555555d383f0, 
    parent=<optimized out>, sibling=<optimized out>, gnode=0x555556166f90, 
    func=0x5555556d3810 <folderview_gnode_func>, data=0x555555f6de00)
    at gtksctree.c:1947
        clist = 0x555555d383f0
        cnode = 0x5555561a8d40
        child = 0x5555561a8da0
        new_child = <optimized out>
        list = 0x5555561a8d40
        work = 0x55555618fef0
        depth = 1
#10 0x00005555556d5c0a in folderview_set_folders (folderview=<optimized out>)
    at folderview.c:1905
        list = <optimized out>
#11 folderview_set (folderview=<optimized out>) at folderview.c:797
        ctree = <optimized out>
        mainwin = <optimized out>
        sel_item = <optimized out>
        op_item = <optimized out>
#12 0x00005555556d6070 in folderview_update_folder (source=<optimized out>, 
    userdata=<optimized out>) at folderview.c:2964
        hookdata = <optimized out>
        folderview = <optimized out>
        ctree = <optimized out>
#13 0x0000555555820287 in hooks_marshal (hook=<optimized out>, data=0x7fffffffba30)
    at hooks.c:107
        func = <optimized out>
        marshal_data = 0x7fffffffba30
#14 0x00007ffff35a6524 in g_hook_list_marshal () from /lib64/libglib-2.0.so.0
No symbol table info available.
#15 0x0000555555820979 in hooks_invoke (
    hooklist_name=hooklist_name@entry=0x555555895f59 "folder_update", 
    source=source@entry=0x7fffffffca80) at hooks.c:125
        hooklist = <optimized out>
        marshal_data = {source = 0x7fffffffca80, abort = 0}
#16 0x00005555556c34a8 in folder_add (folder=0x555556149600) at folder.c:805
        cur_folder = <optimized out>
        cur = <optimized out>
        i = <optimized out>
        hookdata = {folder = 0x555556149600, update_flags = FOLDER_ADD_FOLDER, 
          item = 0x0, item2 = 0x0}
#17 0x00005555556c7908 in folder_read_list () at folder.c:852
        folder = <optimized out>
        node = 0x7fffd0012330
        cur = 0x7fffd0007b20
        xmlnode = <optimized out>
        path = <optimized out>
#18 0x000055555567d2eb in main (argc=<optimized out>, argv=<optimized out>)
    at main.c:1355
        connection = 0x555555dc0888
        error = 0x0
        nm_proxy = 0x555555db03a0
        userrc = <optimized out>
        mainwin = 0x555555df0150
        folderview = 0x555555f6de00
        icon = 0x555555dc8360
        crash_file_present = <optimized out>
        num_folder_class = 0
        asked_for_migration = 0
        start_done = 1
        plug_list = 0x0
        never_ran = 0
        mainwin_shown = 0
        start = {tv_sec = 1514150424, tv_usec = 404862}
        end = {tv_sec = 0, tv_usec = 23712}
        diff = <optimized out>
        timing_name = 0x5555558add15 "startup"
        __FUNCTION__ = "main"
Comment 1 Andrej Kacian 2018-01-07 15:12:05 CET
I replied to your mailing list post sometimed during the holiday break, but I think the reply got eaten during the recent server problems. So, let's try here:

What is the value of "config_version" in your clawsrc file?

What are the values of "protocol" and "config_version" (if any) in
accountrc for the GMX account in accountrc file?
Comment 2 Michael Schwendt 2018-01-07 19:59:14 CET
$ grep config_version ~/.claws-mail/clawsrc
config_version=2
$


The account you ask about is IMAP.

[Account: 20]
account_name=GMX
protocol=0
...


$ grep config_version ~/.claws-mail/accountrc
$
Comment 3 Andrej Kacian 2018-01-09 21:16:54 CET
Are you sure that same configuration dir works with 3.15.x? protocol=0 denotes a POP3 account, so my guess is that you hit some corner case bug in code that made CM think your accountrc needs modification.

If you still have the "working" copy of the .claws-mail dir on a box with 3.15.x installed, please look how the mentioned values look there. That will help me with reproducing the bug you're hitting when trying that configuration dir with 3.16.0.
Comment 4 Michael Schwendt 2018-01-09 22:49:28 CET
> Are you sure that same configuration dir works with 3.15.x? 

Yes, I still use it daily. And it has been used with versions much older than 3.15.1 before.


> protocol=0 denotes a POP3 account,

Wow!

It's IMAP email accounts indeed, trust me. I access the remote folders via IMAP protocol using Claws Mail 3.15.1. One of them is Google Mail with protocol=0, too. I don't use the "Get Mail" feature for any of them.


But your detective work is good nevertheless. In 3.15.1, Folder View shows "IMAP" for these accounts. Edit accounts dialogs show "POP".

Could it be that accessing the same user account with different versions of Claws Mail has lead to an inconsistency? 3.15.1 and older could handle it somehow. 3.16.0 cannot.
Comment 5 Michael Schwendt 2018-01-09 22:51:51 CET
Oh, the Fedora Project SMTP account set up in Claws Mail is shown as "News" in folder view and "NNTP" in the account settings. That makes no sense either.
Comment 6 Michael Rasmussen 2018-01-10 01:00:28 CET
(In reply to comment #5)
> Oh, the Fedora Project SMTP account set up in Claws Mail is shown as "News"
> in folder view and "NNTP" in the account settings. That makes no sense
> either.

You cannot share a claws-mail home between current and old config where old config is before changing the password algorithm. I seem to remember this specific situation where using a version of claws before changing password algorithm resulted in a situation just like yours (All mail accounts where 'reset' to POP)
Comment 7 Michael Rasmussen 2018-01-10 01:03:29 CET
My last post should have read: You cannot use a version of claws before password algorithm change with a claws-home where the configuration file has been converted to the new password algorithm format - behaviour is unknown.

Maybe some test should prevent this situation?
Comment 8 Andrej Kacian 2018-01-10 09:31:41 CET
It's a bit more complicated, unfortunately. Claws Mail will already complain on startup if it finds a config file with config_version higher than it supports. But this is a situation, where between 3.15.1 and 3.16.0, we are adding config_version not only to clawsrc, but to each separate account.

Unless a working time machine is invented, 3.15.1 has no way of knowing that 3.16.0 would do this, and will ignore config_version in your accountrc file - and discard it upon saving the file.

Still, I thought I had this situation handled, that's why I am asking for a sample config directory that works on 3.15.1 (all accounts have correct protocol after two or more restarts of 3.15.1), but breaks with 3.16.0 like in original comment #0 here.
Comment 9 Michael Schwendt 2018-01-10 20:56:26 CET
Re: comment 6

And still 3.15.1 worked fine with exactly the same ~/.claws-mail contents and continue to work. 3.15.1 doesn't crash because of the wrong protocol= versions.


Re: comment 8

The account that crashes with 3.16.0 has __not__ used before with 3.16.0, because that version crashed early as reported. It's a ~/.claws-mail that has been used with 3.15.1 and still works with 3.15.1 despite the messed up protocol= values in the accountrc file.

As when the accountrc file got changed, no idea. It's not as if I change Claws Mail versions frequently. But perhaps a long time ago I've run a newer version and have returned to an older release due to problems. It's a user mistake to do that, if Claws Mail can break, but 3.16.0 is the first version to crash while 3.15.1 has not complained.
Comment 10 Andrej Kacian 2018-01-10 23:56:32 CET
Can you show the complete --debug output from the startup attempt with 3.16.0? Either send to my email privately, or attach it here as a text file. Thanks.
Comment 11 Michael Schwendt 2018-01-11 00:46:16 CET
Created attachment 1836 [details]
claws-mail --debug output with #mh/Mailbox messages removed
Comment 12 Andrej Kacian 2018-01-11 12:30:30 CET
Ok, this is what happened:

Your IMAP account has already been saved in accountrc with protocol=0 (POP3) for a while. Possibly after initial protocols renumbering in 3.14.1 release - there were some bugs which caused it not to work correctly in some cases.

In your case, the renumbering seems to have run at least once more, as IMAP went from protocol=3 to protocol=1 (down by 2), while you have protocol=0.

Before 3.16.0 release, the code that returns local path to an IMAP folder was written as specific for IMAP, so it did not check whether protocol of the account connected with each folder. Therefore it always returned correct path regardless of incorrect protocol= value. 

In 3.16.0, this code was changed to use a function shared for all folder classes (IMAP, MH, mbox, RSSyl, ...), and this function does first check for protocol, in order to decide what to do. And since it did not see an IMAP account connected to the folders, it returns an empty value, which eventually results in the crash you experience.

The fix in your case is to manually correct the protocol= values in accountrc: 0 for a POP3 account, 1 for IMAP, 2 for NNTP, 3 for Local, 4 for SMTP-only.

After that, 3.16.0 should start correctly, and you should also be able to freely switch between 3.16.0 and 3.15.1 with the same config dir.

The original bug, which caused the wrong renumbering has already been fixed, I believe.