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"
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?
$ 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 $
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.
> 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.
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.
(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)
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?
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.
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.
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.
Created attachment 1836 [details] claws-mail --debug output with #mh/Mailbox messages removed
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.