GNOME Bugzilla – Bug 785618
Unread mail count in IMAP folder not always updated
Last modified: 2017-09-13 09:52:19 UTC
Created attachment 356625 [details] Screenshot evolution-3.24.4-1.1.fc26.x86_64 evolution-data-server-3.24.4-1.1.fc26.x86_64 1. I am not connected to a wifi/wlan. 2. Evolution somehow thinks I am online (maybe because I suspended the device when I was connected to a wifi) 3. I go through mail in a subfolder of my GMail inbox and mark some as read 4. The unread count is not updated in some places.
Thanks for a bug report. Could you capture a backtrace of the running evolution when this happens again, please? I'd guess that the folder in question is somehow locked to propagate changes, but I can be wrong. This can be also related to an evolution commit 3df39f3d08e70, which you already have. You can get the backtrace with command like this: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). You know how it works with respect of the debuginfo packages for evolution-data-server and evolution, thus I'm not going to bother you with that.
(In reply to Milan Crha from comment #1) > You can get the backtrace with command like this: > $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt This is a different case though as I am online (after switching from one wifi to another though, might be related) and **none** of the 'unread mail in that folder' indicators updated after I had marked a few unread emails as read: [New LWP 3129] [New LWP 3130] [New LWP 3131] [New LWP 3132] [New LWP 3133] [New LWP 3148] [New LWP 3149] [New LWP 3150] [New LWP 3153] [New LWP 3170] [New LWP 3171] [New LWP 7984] [New LWP 9539] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f44d31dba9d in poll () at ../sysdeps/unix/syscall-template.S:84 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
+ Trace 237733
Thread 14 (Thread 0x7f42b37fe700 (LWP 9539))
I just noticed you even have the test builds which have fixes for the "IMAP flag change in offline" issue. Knowing why it fails on your side, but works on mine, would make it much easier to uncover.
This is super annoying and wastes my time as I need to go through mail *again* to mark it as unread. Anything else I can provide?
I'm missing the reproducer and I've not much idea what to look for, which is even worse. I'm sorry. Regarding your step 2 in comment #0, what is selected in Edit->Preferences->Network Preferences->Method to detect online state? It might be "Default"; try to change it to something else, maybe "networkmanager". Then stop & run evolution (just to make sure the change is fully propagated). If your connection is managed by network manager, then evolution should know when you are online and when offline now. Eventually try other methods.
(In reply to Milan Crha from comment #5) > Regarding your step 2 in comment #0, what is selected in > Edit->Preferences->Network Preferences->Method to detect online state? It > might be "Default"; try to change it to something else Method is set to "Default". I've set it to "networkmanager" and will keep an eye on whether this happens again (normally happens about 2 or 3 times a week).
I tried to reproduce this in a similar environment. I set evolution to be "Always Online", then I went to my account which requires VPN, but that VPN is off. Evolution is quite unhappy, shows plenty of errors about failed operations, but the read/unread flag changes stick in an IMAP folder for me. I noticed that the unread count changes only up in the folder tree, not down, while the window title and the label above folder tree show correct unread count, which reminded me of commit 3df39f3d08e70f3f02. It looks like it's still not perfect, but it's a different issue than that yours, where you claim to be forced to retag messages as read, thus that your previous read/unread changes are not locally stored for later store to the server. I tested this also with 3.24.5, not only with the current development version.
(In reply to Milan Crha from comment #7) > I noticed that the unread count changes only up in the folder tree, not > down... Fixed this with eds commit: https://git.gnome.org/browse/evolution-data-server/commit/?id=6c98483
(In reply to André Klapper from comment #6) > Method is set to "Default". I've set it to "networkmanager" Does not change a thing. Problem still happens several times a week on 3.24.5-1. I still need to capture a backtrace via Ctrl+C, will do that soon.
Created attachment 359350 [details] gdb output Pulled new mail from Gmail IMAP, went into offline mode and synced data for offline use, I tried to manually apply filters in a subfolder, Evo showed me an error as not all mail was synced, I went into online mode again, went into offline mode again and let Evo sync data again. Marking emails as read in that subfolder changes the font from bold to normal in the message list but does not change the unread number in the application title bar, folder pane, grey box above the folder pane. Interesting artifacts: * The bold font does not become normal when pressing Ctrl+K. It is only re-rendered once I use "." to go to the next unread message. * If I mark a message as read (Ctrl+K) and then as unread (Ctrl+Shift+K), the unread count in the folder pane (only there!) increases by one. It does not decrease by one if I mark as read (which is what this task is about). Attaching as BZ barks that "Comments cannot be longer than 65535 characters."
Created attachment 359378 [details] gdb output 2 Same issue but now in online mode, after going online from offline. In a different Gmail IMAP subfolder than earlier today.
Thanks. Both backtraces show evolution basically idle, while I thought there something stuck in the background, which is not the case, which is good. Both backtraces also show one other thing, invalid unref: > (evolution:17065): GLib-GObject-CRITICAL **: g_object_unref: assertion > 'G_IS_OBJECT (object)' failed > > (evolution:17065): GLib-GObject-CRITICAL **: g_object_unref: assertion > 'G_IS_OBJECT (object)' failed I do not see it here, but maybe it's related to the issue. I cannot tell from the message itself, there can be either passed a NULL pointer (which is bad, but doesn't cause issues) or an invalid pointer (like a use-after-free, which can cause "random" issues in some cases). You can catch them with gdb when you run it as this: $ gdb evolution --ex "b g_logv if log_level<=16" --ex r You might have installed debuginfo also for glib2, thus it knows about the arguments. Once gdb stops, get the backtrace of the warning and continue with: (gdb) bt (gdb) c That may happen twice, like it did in both backtraces. I'm wondering where it happens and what address is passed to the g_object_unref(). The sub-issue mentioned in comment #10, about download for offline being unreliable, it's out of scope of this bug report and can depends also on the download limit setting in the account properties, Receiving Options tab, but I do not recall whether 3.24 has it or not. Feel free to open a new bug report for this.
Created attachment 359395 [details] gdb output 3 Might not be the issue itself, but going online after being offline in Evo, gdb stopped. Full output in attachment, only pasting the trace itself here: Thread 1 "evolution" hit Breakpoint 1, g_logv (log_domain=0x7ffff5e9806e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0x7ffff5ea17f4 "%s: assertion '%s' failed", args=args@entry=0x7fffffffd5f0) at gmessages.c:1243 1243 { (gdb) bt
+ Trace 237941
Continuing. (evolution:31299): GLib-CRITICAL **: g_base64_decode_step: assertion 'out != NULL' failed Thread 1 "evolution" hit Breakpoint 1, g_logv (log_domain=0x7ffff5e9806e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0x7ffff5ea17f4 "%s: assertion '%s' failed", args=args@entry=0x7fffffffd590) at gmessages.c:1243 1243 { (gdb) c Continuing. (evolution:31299): GLib-CRITICAL **: g_base64_decode_step: assertion 'out != NULL' failed Thread 1 "evolution" hit Breakpoint 1, g_logv (log_domain=0x7ffff5e9806e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0x7ffff5ea17f4 "%s: assertion '%s' failed", args=args@entry=0x7fffffffd5c0) at gmessages.c:1243 1243 { (gdb) c Continuing. (evolution:31299): GLib-CRITICAL **: g_base64_decode_step: assertion 'out != NULL' failed
Created attachment 359460 [details] Status bar screenshot Was pulling mail and probably also manually moving message to subfolders. [Thread 0x7ffb8ebac700 (LWP 28943) exited]
+ Trace 237947
Thread 140718622926592 (LWP 28909)
(gdb) info register rax 0x7ffb9b8852d0 140718622921424 rbx 0x1 1 rcx 0x7ffb9b8852b0 140718622921392 rdx 0x7ffff5ea17f4 140737319147508 rsi 0x8 8 rdi 0x7ffff152e944 140737242130756 rbp 0x7ffef89b3360 0x7ffef89b3360 rsp 0x7ffb9b8852a8 0x7ffb9b8852a8 r8 0x7ffff1530ab0 140737242139312 r9 0x6 6 r10 0x60 96 r11 0x11 17 r12 0x7ffef84da6a0 140733064259232 r13 0x7ffef872a610 140733066683920 r14 0x0 0 r15 0x55555a4d4640 93825075594816 rip 0x7ffff5e56ec0 0x7ffff5e56ec0 <g_logv> eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) list 1238 void 1239 g_logv (const gchar *log_domain, 1240 GLogLevelFlags log_level, 1241 const gchar *format, 1242 va_list args) 1243 { 1244 gboolean was_fatal = (log_level & G_LOG_FLAG_FATAL) != 0; 1245 gboolean was_recursion = (log_level & G_LOG_FLAG_RECURSION) != 0; 1246 gchar buffer[1025], *msg, *msg_alloc = NULL; 1247 gint i;
Oh and continuing from the last comment, as I hibernated and moved to a different place (hence the disconnect stuff in here): (gdb) c Continuing. [Thread 0x7ffb912a1700 (LWP 28942) exited] (evolution:31299): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Thread 9501 "pool" hit Breakpoint 1, g_logv (log_domain=0x7ffff152e944 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=0x7ffff5ea17f4 "%s: assertion '%s' failed", args=args@entry=0x7ffb9b8852b0) at gmessages.c:1243 1243 { (gdb) bt
+ Trace 237948
Thread 140719489046272 (LWP 28905)
Thread 140719456589568 (LWP 28917)
Continuing. [Thread 0x7ffbcf285700 (LWP 28905) exited] [Thread 0x7ffb8ebac700 (LWP 30042) exited] (evolution:31299): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: Operation was cancelled [Switching to Thread 0x7ffb9b886700 (LWP 28909)] Thread 9501 "pool" hit Breakpoint 1, g_logv (log_domain=0x7ffff5e9806e "GLib", log_level=G_LOG_LEVEL_WARNING, format=0x7ffff5e9c340 "GError set over the top of a previous GError or uninitialized memory.\nThis indicates a bug in someone's code. You must ensure an error is NULL before it's set.\nThe overwriting error message was: %s", args=args@entry=0x7ffb9b885480) at gmessages.c:1243 1243 { (gdb) c Continuing. (evolution:31299): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: You must be working online to complete this operation [New Thread 0x7ffb8ebac700 (LWP 30044)] [New Thread 0x7ffbcf285700 (LWP 30045)] [New Thread 0x7ffb8e3ab700 (LWP 30046)] [New Thread 0x7ffb9b085700 (LWP 30047)] [New Thread 0x7ffbc9c12700 (LWP 30048)] [New Thread 0x7ffb9310d700 (LWP 30049)] [New Thread 0x7ffb90aa0700 (LWP 30050)] [Thread 0x7ffb912a1700 (LWP 30040) exited] evolution-shell-Message: Connection established. Going online. [New Thread 0x7ffb912a1700 (LWP 30051)] [Thread 0x7ffb912a1700 (LWP 30051) exited] [New Thread 0x7ffb912a1700 (LWP 30052)] [New Thread 0x7ffb9029f700 (LWP 30053)] [New Thread 0x7ffb8ccb8700 (LWP 30054)] [New Thread 0x7ffb8c4b7700 (LWP 30055)] [New Thread 0x7ffb8bcb6700 (LWP 30056)] [Thread 0x7ffb9b085700 (LWP 30047) exited] [Thread 0x7ffbc9c12700 (LWP 30048) exited] [Thread 0x7ffb8e3ab700 (LWP 30046) exited] [Thread 0x7ffb90aa0700 (LWP 30050) exited] [Thread 0x7ffb9310d700 (LWP 30049) exited] [Thread 0x7ffb9029f700 (LWP 30053) exited] [Thread 0x7ffb912a1700 (LWP 30052) exited] [Thread 0x7ffb8bcb6700 (LWP 30056) exited] [Thread 0x7ffb8ccb8700 (LWP 30054) exited] [Thread 0x7ffb98aa0700 (LWP 28923) exited] [Thread 0x7ffb9b886700 (LWP 28909) exited] [Thread 0x7ffb8c4b7700 (LWP 30055) exited] [Thread 0x7ffbcd391700 (LWP 28917) exited] [Thread 0x7ffbcf285700 (LWP 30045) exited]
Okay, enough to update to Fedora 26 and I can (suddenly) reproduce it too. I'm wondering what broke it, might be even glib2, but whatever. Good news for you is that it's not needed to update backtraces anymore.
Let's use this bug report for the initial issue, unread count not always updating. That failed g_object_unref() seems like happening when moving some messages which are not in the source folder's summary yet and it happens when some message filter moves the message from one folder to another and then the source message is deleted and moved to the Trash folder (that's complicated, right). I will investigate it further later. Created commit d86f2064e1 in evo master (3.27.1+) Created commit 92cc8b127a in evo gnome-3-26 (3.26.1+)
I forgot to mention, maybe if you'd like to give a quick test to the change you can do it when following the steps from here: https://wiki.gnome.org/Apps/Evolution/Flatpak
(In reply to André Klapper from comment #15) > Oh and continuing from the last comment, as I hibernated and moved to a > different place (hence the disconnect stuff in here): The first wrong g_object_unref() is described in comment #17. I suspect the object is NULL, thus no big deal (it will not break anything in the memory), but I just noticed that there is a continuation, which shows: > evolution-shell-Message: Network disconnected. Forced offline. and right after that there's a catch of: > (evolution:31299): GLib-GObject-CRITICAL **: g_object_ref: assertion > 'object->ref_count > 0' failed That shows a ref/unref imbalance, something which can cause harm eventually. Pity you didn't get backtrace of it too.
I just tried and I cannot reproduce even that filtering runtime warning, my newly received message is moved (to a subfolder of my Gmail account) after being received in the Inbox (of the same Gmail account) and no such warning on the console. Having two "Move message to" filter rules applying to the same message also doesn't matter, because the first move explicitly stops further filter rule processing. I'm out of idea on the two left issues.