GNOME Bugzilla – Bug 782096
Folder unread count sometimes doesn't update properly
Last modified: 2017-05-29 19:56:56 UTC
A message gets delivered into a folder other than inbox and Evo correctly increases the number of unread on the folder to 1 (i.e. via IMAP NOTIFY). If I then check e-mail from another device and delete the received message in that folder, the folder will get updated in Evo (i.e. Evo will not show the delete message in the list any more), but the number of unread messages will remain 1 until I manually Send/Receive.
Thanks for a bug report. These steps work properly for me. I think what you face is [1]. I'll pair the two once I know the result from the downstream bug report. Please do not close this one. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1440068
I've been able to reproduce this finally, with these steps sent to me: 1. I created a new user 2. I used GOA to set up a new google account 3. I confirmed that I had the right evolution builds installed 4. I ran evolution from the terminal 5. I changed the switcher appearance to icons only 6. I updated the receiving options for the account 7. I clicked "receive all" to update all folders (this took a bit of time) 8. I went over most folders to update the folder view 9. After all folders had been updated, and evolution was idle, I reproduced the bug using the "xxx" folder: - the first time the folder is updated, the bug doesn't occur - an unread e-mail message is toggled to read when selected. - subsequent times, though, marking messages as read/unread only increases the unread count. An unread message that is selected does not toggle to read on its own either. ------------------------------------------------------------------------------ That helped me to investigate and turned out that there had been a message info memory leak (due to ref/unref imbalance) causing the misbehaviour. The thing is that GWeakRef is awfully slow when there are many objects referencing one object this way, which is the case for message infos, where each single message info "weak-references" its summary (we speak of thousands of messages in the folder). Due to that I added CamelWeakRefGroup, which avoids this GWeakRef limitation. The group works properly as long as is is updated when the referenced object is freed, which didn't happen here, due to message info being leaked. This happened always when changing message flags (or basically message info as such), but the issue about unread count not being updated triggered only if the new folder summary occupied the same memory as one of the already registered group in the CamelWeakRefGroup. In that case the flag change of the message info had not been propagated further, because CamelWeakRefGroup returned NULL summary, because that pointer had been used for previously freed summary. That's basically it. It's very complicated, even to describe. Anyway, I fixed the memory leak (which I caused) and it fixed the issue. Because it's generally impossible to catch all the leaks (Camel can be used by anything, not only by Evolution), then I added a private function which is called when the summary is freeing all its message infos, thus this issue won't raise again in case some other code would cause imbalance of ref/unref on CamelMessageInfo. Created commit f68fb2e in eds master (3.25.3+) Created commit 8852b13 in eds gnome-3-24 (3.24.3+)
*** Bug 782842 has been marked as a duplicate of this bug. ***