[Akonadi] [Bug 338658] GMail, Novell Groupwise, other IMAP: "Multiple merge candidates, aborting"
https://bugs.kde.org/show_bug.cgi?id=338658 --- Comment #97 from Joshua Clayton --- I looked really hard for it and didn't find it yesterday... but somehow when I looked again this morning it is the second result. My patch was attached to https://bugs.kde.org/show_bug.cgi?id=376808 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Akonadi] [Bug 338658] GMail, Novell Groupwise, other IMAP: "Multiple merge candidates, aborting"
https://bugs.kde.org/show_bug.cgi?id=338658 --- Comment #95 from Joshua Clayton --- The bug is this: emails contain an ID field in the header, usually a combination of a timestamp + source ip or email address kmail assumes that this ID is unique, but does a query that can return multiple results. It pukes every time duplicate emails are returned and it never recovers from this status. I proposed a fairly simple patch to fix this, just select the first result from the query, and be done with it. Sadly, the maintainer was unwilling to accept it, and the bug remains open Usually these duplicates are multiple references to the same email, via filters, or similar things. (I have accidentally generated different emails with the same id, while messing with git-send-email, but that is an extremely rare edge case and I was doing wrong things out of ignorance at the time) I can no longer find which bug report my was attached to. It has been too long, Sorry. On Sun, Mar 18, 2018 at 11:56 PM, Steven Haigh wrote: > https://bugs.kde.org/show_bug.cgi?id=338658 > > --- Comment #94 from Steven Haigh --- > Interestingly, I disabled the local filters on my gmail account today from > within Kmail and haven't had to restart akonadi all day. > > Maybe there is something within the local filters that causes things to > die? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Akonadi] [Bug 376808] Akonadi stuck on retrieving folder content, ItemFetchJob Stuck, Failed: Multiple Merge Candidates
https://bugs.kde.org/show_bug.cgi?id=376808 --- Comment #10 from Joshua Clayton --- Hi, Daniel. I hear what you are saying in theory, but the current situation with kmail/kontact is worse, with mail sync cycles just hanging and the program becoming inoperable, sometimes becoming usable again by restarting akonadi, and sometimes requiring the db to be deleted. In practice email message ID's may be duplicated in terms of actual copies, but each copy should contain exactly the same message. The current behavior is clearly wrong. Either it should be updating ALL the entries, or if it is just returning a reference to the content, then any one of them will do (I was understanding it to be the second). Can you tell me which it is? Maybe I'm misunderstanding how this is being used. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 376808] Akonadi stuck on retrieving folder content, ItemFetchJob Stuck, Failed: Multiple Merge Candidates
https://bugs.kde.org/show_bug.cgi?id=376808 --- Comment #8 from Joshua Clayton --- The patch above is compile tested. The patch applies and builds across a wide range of versions, but finding the right version and variables to work with kubuntu 17.04's kf5 5.31 -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 376808] Akonadi stuck on retrieving folder content, ItemFetchJob Stuck, Failed: Multiple Merge Candidates
https://bugs.kde.org/show_bug.cgi?id=376808 Joshua Clayton changed: What|Removed |Added CC||stillcompil...@gmail.com --- Comment #7 from Joshua Clayton --- Created attachment 105826 --> https://bugs.kde.org/attachment.cgi?id=105826&action=edit Patch to have akonadi return the first result if her are multiple log multiple merge candidates as an error, but rather than returning nothing, return the first result. This seems like a less bad result than the stalls that currently happen in kmail/kontact. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 352249] kmail ... gmail Syncing folder 'linux-arm-kernel' hangs at 98%
https://bugs.kde.org/show_bug.cgi?id=352249 --- Comment #1 from Joshua Clayton --- I recently went back and set this folder to expire old emails. I allowed kmail to delete the old emails, and on the subsequent login the problem was gone. To me this means it is likely a problem with a too large IMAP folder. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 352249] New: kmail ... gmail Syncing folder 'linux-arm-kernel' hangs at 98%
https://bugs.kde.org/show_bug.cgi?id=352249 Bug ID: 352249 Summary: kmail ... gmail Syncing folder 'linux-arm-kernel' hangs at 98% Product: Akonadi Version: 1.13.0 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: grave Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: stillcompil...@gmail.com CC: kdepim-bugs@kde.org, vkra...@kde.org synching one gmail folder with a lot of mail hangs at 98%. Reproducible: Always Steps to Reproduce: The progress bar for the folder sync proceeds slowly to 98% and stops. After this, all actions stall. I can't even open an email in a different folder such as local sent mail. stopping and restarting akonadi via akonadictl looks fine. No errors. When the sync process again hits 98% and again hangs the following two lines are printed: 47642 "19180" "" 47662 "19180" "" Actual Results: kmail becomes inoperable. Expected Results: sync will finish, time out, explode... SOMETHING?! 1) If the process cannot continue it should not hang indefinetly 2) I should be able to access other folders even if one background process is stuck. Something similar to this has happened several times now. Each time the "solution" has been to wipe out ~/.local/share/akonadi, which has bad effects. It takes a long time to sync up again, some settings are preserved, some are gone, and some, like filter settings are still there but are all screwed up. I like kmail and I would like to help track this down so that I can continue to use it. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 344270] kmail crashed on restart
https://bugs.kde.org/show_bug.cgi?id=344270 Joshua Clayton changed: What|Removed |Added CC||stillcompil...@gmail.com --- Comment #2 from Joshua Clayton --- In my case, a mailing-list filter hung, so I stopped akonadi, closed kmail. kmail crashed on restart. Logging completely out is the only way to get it back into a working state. Another possible clue: when started from the command line, I get the following warning: me@my-pc:~$ kmail QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. Application: KMail (kmail), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f47a25c3800 (LWP 3296))] Thread 5 (Thread 0x7f477ac14700 (LWP 3383)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f4793c3981d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f4793c39859 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f479d1076aa in start_thread (arg=0x7f477ac14700) at pthread_create.c:333 #4 0x7f479f864eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f4739a81700 (LWP 3421)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f479397a20d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f4793c68fd6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f479d1076aa in start_thread (arg=0x7f4739a81700) at pthread_create.c:333 #4 0x7f479f864eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7f4738e23700 (LWP 3425)): #0 0x7f479f8598dd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f47974ccebc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f47974ccfcc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f47a0efd82e in QEventDispatcherGlib::processEvents (this=0x7f472c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452 #4 0x7f47a0ecccd1 in QEventLoop::processEvents (this=this@entry=0x7f4738e22dd0, flags=...) at kernel/qeventloop.cpp:149 #5 0x7f47a0ecd035 in QEventLoop::exec (this=this@entry=0x7f4738e22dd0, flags=...) at kernel/qeventloop.cpp:204 #6 0x7f47a0dc0e89 in QThread::exec (this=) at thread/qthread.cpp:538 #7 0x7f47a0dc36ff in QThreadPrivate::start (arg=0x288fc30) at thread/qthread_unix.cpp:349 #8 0x7f479d1076aa in start_thread (arg=0x7f4738e23700) at pthread_create.c:333 #9 0x7f479f864eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 2 (Thread 0x7f47313f7700 (LWP 3688)): #0 0x7ffd9e3eec2e in clock_gettime () #1 0x7f479f87338d in __GI___clock_gettime (clock_id=, tp=) at ../sysdeps/unix/clock_gettime.c:115 #2 0x7f47a0e1aac5 in do_gettime (frac=, sec=) at tools/qelapsedtimer_unix.cpp:127 #3 qt_gettime () at tools/qelapsedtimer_unix.cpp:144 #4 0x7f47a0efe635 in updateCurrentTime (this=0x7f4728002ee0) at kernel/qeventdispatcher_unix.cpp:354 #5 QTimerInfoList::timerWait (this=0x7f4728002ee0, tm=...) at kernel/qeventdispatcher_unix.cpp:460 #6 0x7f47a0efceec in timerSourcePrepareHelper (src=, timeout=0x7f47313f6bb4) at kernel/qeventdispatcher_glib.cpp:143 #7 0x7f47a0efcfb5 in timerSourcePrepare (source=, timeout=) at kernel/qeventdispatcher_glib.cpp:176 #8 0x7f47974cc3fd in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x7f47974ccde8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x7f47974ccfcc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7f47a0efd82e in QEventDispatcherGlib::processEvents (this=0x7f47280008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:452 #12 0x7f47a0ecccd1 in QEventLoop::processEvents (this=this@entry=0x7f47313f6d80, flags=...) at kernel/qeventloop.cpp:149 #13 0x7f47a0ecd035 in QEventLoop::exec (this=this@entry=0x7f47313f6d80, flags=...) at kernel/qeventloop.cpp:204 #14 0x7f47a0dc0e89 in QThread::exec (this=this@entry=0x468dfa0) at thread/qthread.cpp:538 #15 0x7f47a0ead443 in QInotifyFileSystemWatcherEngine::run (this=0x468dfa0) at io/qfilesystemwatcher_inotify.cpp:265 #16 0x7f47a0dc36ff in QThreadPrivate::start (arg=0x468dfa0) at thread/qthread_unix.cpp:349 #17 0x7f479d1076aa in start_thread (arg=0x7f47313f7700) at pthread_create.c:333 #18 0x7f479f864eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f47a25c3800 (LWP 3296)): [KCrash Handler] #6 0x7f47a210e411 in KStatusNotifierItem::setStatus (this=this@entry=0x2b13d50, status=status@entry=KStatusNotifierItem::Active) at ../../kdeui/notifications/kstatusnotifieritem.
