[Akonadi] [Bug 338658] GMail, Novell Groupwise, other IMAP: "Multiple merge candidates, aborting"
https://bugs.kde.org/show_bug.cgi?id=338658 --- Comment #127 from Matthias Kretz --- The fact that I can have an inconsistent state stored in my Akonadi DB is telling. Apparently, while clients interact with Akonadi, the DB goes through inconsistent states. Those appear to be open to races, and unfortunate interrupts (crash, system hang, power loss). What I'd do (and I'm guessing from a far away distance in the hopes it helps inspire a real fix, hoping not to step on any toes): 1. Update the DB schema to enforce consistent state. In particular all foreign keys need to be defined so that it's impossible to DELETE FROM parttable while something in pimitemtable still holds a key to it. 2. Presumably this will break clients which rely on the DB to allow inconsistent intermediate states. DB updates therefore need to be fixed to atomically go from one consistent state to the next. E.g. use DELETE together with INNER JOIN. 3. Races like "unread -> read -> unread" need to be guarded against via compare-exchange atomic operations using some modification counter. E.g. mailcheck create id=X, state=unread kmail read id=X, state=unread kmail write state=read WHERE id=X mailcheck update id=X, state=unread (why would this happen anyway, can the IMAP server indicate some update of metadata?) If we add a version the UPDATE could be predicated on the version column still storing the same value as when it was SELECTED before. E.g. the mail client does `UPDATE foo SET state=read WHERE id=X AND version=1` instead of `UPDATE foo SET state=read WHERE id=X`. I actually expect Akonadi already has such a facility and Allans guess is incorrect. I have another guess from looking at my logs. I have lots of: org.kde.pim.akonadiserver: DB error: "Lock wait timeout exceeded; try restarting transaction" org.kde.pim.akonadiserver: Error text: "Lock wait timeout exceeded; try restarting transaction QMYSQL3: Unable to execute statement" I.e. KMail updates the UI to read state, tries to reflect the state change with Akonadi, but the DB is locked up. The UPDATE fails, and the KMail UI reverts to the state stored in Akonadi. These locks might also be the reason why inconsistent entries in tables remain. A first DELETE goes through, the second (to make it consistent again) times out. I have no clue where the locks come from though. One data point: After my DELETE FROM statement above I've not seen a single DB error message about lock timeouts again. Before I had lots. -- 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 #123 from Matthias Kretz --- (In reply to Allan Sandfeld from comment #122) > With my patch in place the duplicates can be removed by simply calling > "remove duplicates" from KMail. "Folder -> Remove Duplicates"? If that removes stales in the pimitemtable it's somewhat misleadingly named. I was expecting it to search for copies of the same mail (i.e. different local & remote ID but equal payload data). -- 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 Matthias Kretz changed: What|Removed |Added CC||kr...@kde.org --- Comment #121 from Matthias Kretz --- I'm fed up with wiping my Akonadi data every other month so I'm trying to once again to understand the cause or find a workaround. Anyway, I was following the SQL hints on debugging the state of my Akonadi data and found three instances of duplicated (well, rather "multiplicated") pimitemtable.remoteIds, on the order of hundreds of different pimitemtable.ids. I then tried to find the corresponding data in parttable via INNER JOIN parttable ON pimitemtable.id = parttable.pimItemId. Interestingly enough there's a single pimitemtable.id per pimitemtable.remoteId left (with three different parttable.id per pimitemtable.id, which seems to be correct for normal entries). So it seems there are stale entries in pimitemtable. The query SELECT pimitemtable.*, collectiontable.name FROM pimitemtable INNER JOIN collectiontable ON pimitemtable.collectionId = collectiontable.id LEFT JOIN parttable ON pimitemtable.id = parttable.pimItemId WHERE parttable.id IS NULL lists the same remoteIds that the query looking for dups found, minus the ones that have a match in parttable. Useful information: there are no additional stale entries in pimitemtable than the dups. Next step, I tried to remove the stale entries in pimitemtable with the following query: DELETE pimitemtable FROM pimitemtable LEFT JOIN parttable ON pimitemtable.id = parttable.pimItemId WHERE parttable.id IS NULL However, the query hangs akonadiconsole for ~1 minute and then returns "Lock wait timeout exceeded; try restarting transaction QMYSQL: Unable to execute query". An `akonadictl restart` in this case did the trick and the query then got through. All dups gone. In any case the hangs on reading mails in KMail that I experienced since yesterday are gone. Let's see whether it helps. Maybe the DELETE query is a useful addition to `akonadictl fsck` until the root cause can be fixed? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[kontact] [Bug 362817] Kontact crash on open addressbook from the email window
https://bugs.kde.org/show_bug.cgi?id=362817 --- Comment #16 from Matthias Kretz --- FWIW, I'm on KMail/Kontact 5.5.3, akonadiserver 5.5.3, KDE neon User Edition 5.10, and I'm not seeing the crash anymore. I have not replaced config files, Mail storage, or anything else. Just regular updates through KDE neon. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 362817] Kontact crash on open addressbook from the email window
https://bugs.kde.org/show_bug.cgi?id=362817 Matthias Kretz changed: What|Removed |Added CC||kr...@kde.org --- Comment #6 from Matthias Kretz --- I can reproduce the issue every time I do: * open composer * press "Select" button for To/CC/BCC address * crash. kmail, kontact, and akonadiserver report version 5.4.0 (I have a KDE neon User Edition 5.8 installation). -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 356116] Kmail crashes when forwarding mails
https://bugs.kde.org/show_bug.cgi?id=356116 Matthias Kretz changed: What|Removed |Added CC||kr...@kde.org --- Comment #2 from Matthias Kretz --- I just got a very similar crash backtrace on the following activity: * new mail * click 'Select' button on To: field * the dialog opens and is unresponsive, waiting for the contact data to come in (this blocking UI - and the time it takes might be worth a bug report itself). * the dialog shows the contact data for half a second * crash ## Comment on the backtrace The `0x0` in `#31 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0` looks suspicious. ## Backtrace Application: Kontact (kontact), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f885ef7f880 (LWP 25653))] Thread 7 (Thread 0x7f883ce89700 (LWP 25655)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f885b26d48b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #2 0x7f885b26d4c9 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #3 0x7f88569ec6aa in start_thread (arg=0x7f883ce89700) at pthread_create.c:333 #4 0x7f885c15feed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 6 (Thread 0x7f87f57d1700 (LWP 25656)): #0 0x7f885c15049d in read () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f8855db24e0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8855d6ecd4 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f8855d6f190 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f8855d6f2fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f885cc9529b in QEventDispatcherGlib::processEvents (this=0x7f87f8c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #6 0x7f885cc3b75a in QEventLoop::exec (this=this@entry=0x7f87f57d0d40, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #7 0x7f885ca593d4 in QThread::exec (this=) at thread/qthread.cpp:503 #8 0x7f885ca5e2be in QThreadPrivate::start (arg=0xb59a60) at thread/qthread_unix.cpp:337 #9 0x7f88569ec6aa in start_thread (arg=0x7f87f57d1700) at pthread_create.c:333 #10 0x7f885c15feed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7f87efcb2700 (LWP 25657)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f885af7b5b4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #2 0x7f885b29d341 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #3 0x7f88569ec6aa in start_thread (arg=0x7f87efcb2700) at pthread_create.c:333 #4 0x7f885c15feed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f87ef4b1700 (LWP 25658)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f885af7c5e3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #2 0x7f885b29d341 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #3 0x7f88569ec6aa in start_thread (arg=0x7f87ef4b1700) at pthread_create.c:333 #4 0x7f885c15feed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7f87eecb0700 (LWP 25659)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f885af7c5e3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #2 0x7f885b29d341 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #3 0x7f88569ec6aa in start_thread (arg=0x7f87eecb0700) at pthread_create.c:333 #4 0x7f885c15feed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 2 (Thread 0x7f87ee4af700 (LWP 25660)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f885af7c5e3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #2 0x7f885b29d341 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5 #3 0x7f88569ec6aa in start_thread (arg=0x7f87ee4af700) at pthread_create.c:333 #4 0x7f885c15feed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f885ef7f880 (LWP 25653)): [KCrash Handler] #6 QSortFilterProxyModelPrivate::index_to_iterator (this=0x3609120, proxy_index=...) at itemmodels/qsortfilterproxymodel.cpp:185 #7 QSortFilterProxyModelPrivate::proxy_to_source (proxy_index=..., this=0x3609120) at itemmodels/qsortfilterproxymodel.cpp:375 #8 QSortFilterProxyModel::mapToSource (proxyIndex=..., this=0x70737c0) at itemmodels/qsortfilterproxymodel.cpp:2716 #9 QSortFilterProxyModelPrivate::store_persistent_indexes (this=this@entry=0x36
[Bug 288141] Kontact crash on exit
https://bugs.kde.org/show_bug.cgi?id=288141 Matthias Kretz changed: What|Removed |Added CC||kr...@kde.org --- Comment #16 from Matthias Kretz --- Application: kontact (4.9.2) KDE Platform Version: 4.9.2 Qt Version: 4.8.3 Distribution: Ubuntu 12.10 In my case Kontact shuts down cleanly on Ctrl+Q. When I stop the Plasma Activity where Kontact sits on, I always get this crash. ( #7 0x0040337e in qDeleteAll::const_iterator> (end=..., begin=...) at /usr/include/qt4/QtCore/qalgorithms.h:322 #8 qDeleteAll > (c=...) at /usr/include/qt4/QtCore/qalgorithms.h:330 #9 main (argc=3, argv=0x7e7f7868) at ../../../kontact/src/main.cpp:220 ) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Bug 255744] Akregator 1.6.2 crashes on start
https://bugs.kde.org/show_bug.cgi?id=255744 Matthias Kretz changed: What|Removed |Added Version|1.6.2 |4.9.2 --- Comment #4 from Matthias Kretz --- There were three mk4 files in my Akregator archives that I had to delete in order for Akregator to start again. You'll find one of them at http://compeng.uni-frankfurt.de/~kretz/https___github.com_MetaScale_nt2_commits_master.atom.mk4 . The feed URL for this archive file is: https://github.com/MetaScale/nt2/commits/master.atom (Attaching to this bugreport won't work because the file is too big.) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Bug 255744] Akregator 1.6.2 crashes on start
https://bugs.kde.org/show_bug.cgi?id=255744 Matthias Kretz changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||kr...@kde.org Ever confirmed|0 |1 --- Comment #3 from Matthias Kretz --- Hi, I have the same problem. I don't need to post my backtrace as it is the same as already posted here. Before this problem started I had a GPU crash, which took down the X server. I was able to sync and unmount via SysRq keys, but I assume some file, that Akregator is now trying to parse, got into an unexpected state. I'll try to find the relevant file. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Bug 295484] filtering removes email's content
https://bugs.kde.org/show_bug.cgi?id=295484 Matthias Kretz changed: What|Removed |Added CC||kr...@kde.org --- Comment #17 from Matthias Kretz --- I think I have the same issue. I have no idea how to reproduce it reliably, but it seems the issue only happens at KMail startup for me. KMail is configured to pipe all mails from my IMAP inbox through bogofilter and then move spam to a different IMAP folder. In other words, if I start KMail when Akonadi was already running and there are new mails in my inbox, then there is a good chance I will get problems: empty mails or header-only mails in my inbox. Today I also found spam (also tagged as such by bogofilter in the header) in my inbox that contained the complete mail (header and body), but was shown as "(No Subject) Unknown Unknown" in the message list. (KMail 4.8.2, Akonadi 1.7.2) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Bug 281704] Mails were deleted after moving folder
https://bugs.kde.org/show_bug.cgi?id=281704 Matthias Kretz changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||kr...@kde.org Ever Confirmed|0 |1 Severity|major |critical --- Comment #1 from Matthias Kretz 2012-01-30 12:17:04 --- I also experienced this bug (well, it seems to be the same) yesterday. Here's what I did: * open a folder with 900 mails (~200 MB) * move all contained mails to a different folder on the same IMAP account There was no feedback about an ongoing transfer of mails. After I closed Kontact and opened it up again only 137 mails (13 MB) were in the destination folder. The source folder was empty. I checked the maildir on the mailserver (dovecot) and saw that the IMAP server was in sync with what KMail showed. Additional details: * The account is accessed via a 1 Mbit uplink (~1/2h required for upload) * The account is set to go offline when KMail closes. * KDE SC / KMail 4.8.0 (Kubuntu packages) changing severity to grave because of "loss of data" -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Bug 290617] KMail (Kontact) crashes on quit
https://bugs.kde.org/show_bug.cgi?id=290617 --- Comment #2 from Matthias Kretz 2012-01-06 21:15:19 --- yes, this looks likely to be the same issue. I'm waiting for RC2 packages. But in any case I did not get the same backtrace again, so I can't reproduce the issue anyway. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Bug 290682] New: Kontact crashes in Akonadi code after Akonadi was stopped and started
https://bugs.kde.org/show_bug.cgi?id=290682 Summary: Kontact crashes in Akonadi code after Akonadi was stopped and started Product: kontact Version: unspecified Platform: Ubuntu Packages OS/Version: Linux Status: NEW Severity: crash Priority: NOR Component: general AssignedTo: kdepim-bugs@kde.org ReportedBy: kr...@kde.org Application: kontact (4.8 rc1) KDE Platform Version: 4.7.95 (4.8 RC1 (4.7.95) Qt Version: 4.7.4 Operating System: Linux 3.0.0-14-generic x86_64 Distribution: Ubuntu 11.10 -- Information about the crash: - What I was doing when the application crashed: Every 5 minutes (the check interval of the IMAP account) I got a lot (> 20) of warning messages ": There is currently no session to the IMAP server available.". To get rid of the problem (which reliably made knotify4 hang after a few occurrences) I wanted to try to stop and start the Akonadi server. When the notification "The Akonadi server has been started and can be used now." appeared Kontact crashed immediately. -- Backtrace: Application: Kontact (kontact), signal: Aborted [Current thread is 1 (Thread 0x7f09c37ab7a0 (LWP 29070))] Thread 4 (Thread 0x7f09a9725700 (LWP 29071)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7f09c0011c2c in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f09c0011d59 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f09bb7f5efc in start_thread (arg=0x7f09a9725700) at pthread_create.c:304 #4 0x7f09c0d1f89d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () Thread 3 (Thread 0x7f09a8e24700 (LWP 29072)): #0 0x7f09c0d13773 in __GI___poll (fds=, nfds=, timeout=) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7f09bb323f68 in g_main_context_poll (n_fds=1, fds=0x10f2510, timeout=8855, context=0x10f2620, priority=) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3402 #2 g_main_context_iterate (context=0x10f2620, block=, dispatch=1, self=) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3084 #3 0x7f09bb324429 in g_main_context_iteration (context=0x10f2620, may_block=1) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3152 #4 0x7f09c147bf3e in QEventDispatcherGlib::processEvents (this=0x10f22f0, flags=) at kernel/qeventdispatcher_glib.cpp:424 #5 0x7f09c144fcf2 in QEventLoop::processEvents (this=, flags=...) at kernel/qeventloop.cpp:149 #6 0x7f09c144fef7 in QEventLoop::exec (this=0x7f09a8e23de0, flags=...) at kernel/qeventloop.cpp:201 #7 0x7f09c136727f in QThread::exec (this=) at thread/qthread.cpp:498 #8 0x7f09c1369d05 in QThreadPrivate::start (arg=0x10f14e0) at thread/qthread_unix.cpp:331 #9 0x7f09bb7f5efc in start_thread (arg=0x7f09a8e24700) at pthread_create.c:304 #10 0x7f09c0d1f89d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x in ?? () Thread 2 (Thread 0x7f095b9e5700 (LWP 30895)): #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 #1 0x7f09c0cbc9df in _L_lock_10501 () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7f09c0cbad71 in __GI___libc_free (mem=0x7f09c0fd81c0) at malloc.c:3736 #3 0x7f09bb31f4e1 in g_source_unref_internal (source=0x7a32810, context=0x20e8580, have_lock=0) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:1702 #4 0x7f09c147bc37 in QEventDispatcherGlib::~QEventDispatcherGlib (this=0x19169d0, __in_chrg=) at kernel/qeventdispatcher_glib.cpp:373 #5 0x7f09c147be49 in QEventDispatcherGlib::~QEventDispatcherGlib (this=0x19169d0, __in_chrg=) at kernel/qeventdispatcher_glib.cpp:401 #6 0x7f09c1368e34 in QThreadPrivate::finish (arg=0x7f09c1784580) at thread/qthread_unix.cpp:367 #7 0x7f09c1369d0d in ~__pthread_cleanup_class (this=, __in_chrg=) at /usr/include/pthread.h:545 #8 ~__pthread_cleanup_class (this=, __in_chrg=) at thread/qthread_unix.cpp:824 #9 QThreadPrivate::start (arg=0x7f09c1784580) at thread/qthread_unix.cpp:290 #10 0x7f09bb7f5efc in start_thread (arg=0x7f095b9e5700) at pthread_create.c:304 #11 0x7f09c0d1f89d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x in ?? () Thread 1 (Thread 0x7f09c37ab7a0 (LWP 29070)): [KCrash Handler] #6 0x7f09c0c743a5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #7 0x7f09c0c77b0b in __GI_abort () at abort.c:92 #8 0x7f09c0cac113 in __libc_message (do_abort=2, fmt=0x7f09c0d9d0d8 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #9 0x7f09c0cb6a96 in malloc_printerr (action=3, str=0x7f09c0d9a0d2 "corrupted double-linked list", ptr=) at malloc.c:6283 #10 0x7f09c0cb6e68 in malloc_consolidate (av=0x7f09c0fd81c0) at malloc.c:5161 #11 0x7f09c0cb7659 in malloc_consolidate (av=0x7f09c0fd81c0) at malloc.c:5115 #12
[Bug 290617] New: KMail (Kontact) crashes on quit
https://bugs.kde.org/show_bug.cgi?id=290617 Summary: KMail (Kontact) crashes on quit Product: kontact Version: unspecified Platform: Ubuntu Packages OS/Version: Linux Status: NEW Severity: crash Priority: NOR Component: general AssignedTo: kdepim-bugs@kde.org ReportedBy: kr...@kde.org Application: kontact (4.8 rc1) KDE Platform Version: 4.7.95 (4.8 RC1 (4.7.95) Qt Version: 4.7.4 Operating System: Linux 3.0.0-14-generic x86_64 Distribution: Ubuntu 11.10 -- Information about the crash: - What I was doing when the application crashed: Kontact was running for a few hours. It crashed when I shut it down via Ctrl+Q. Akonadi is configured to check two IMAP accounts, where one of them is a Kolab server (and configured as such). The non-Kolab IMAP account also contains "groupware folders", i.e. a folder where contacts are stored. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault [Current thread is 1 (Thread 0x7f5ec78c47a0 (LWP 16648))] Thread 5 (Thread 0x7f5ead83f700 (LWP 16649)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7f5ec412ac2c in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f5ec412ad59 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f5ebf90eefc in start_thread (arg=0x7f5ead83f700) at pthread_create.c:304 #4 0x7f5ec4e3889d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () Thread 4 (Thread 0x7f5eacf3e700 (LWP 16650)): #0 0x7f5ec4e2c773 in __GI___poll (fds=, nfds=, timeout=) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x7f5ebf43cf68 in g_main_context_poll (n_fds=1, fds=0x2296060, timeout=2108, context=0x22947f0, priority=) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3402 #2 g_main_context_iterate (context=0x22947f0, block=, dispatch=1, self=) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3084 #3 0x7f5ebf43d429 in g_main_context_iteration (context=0x22947f0, may_block=1) at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3152 #4 0x7f5ec5594f3e in QEventDispatcherGlib::processEvents (this=0x22945b0, flags=) at kernel/qeventdispatcher_glib.cpp:424 #5 0x7f5ec5568cf2 in QEventLoop::processEvents (this=, flags=...) at kernel/qeventloop.cpp:149 #6 0x7f5ec5568ef7 in QEventLoop::exec (this=0x7f5eacf3dde0, flags=...) at kernel/qeventloop.cpp:201 #7 0x7f5ec548027f in QThread::exec (this=) at thread/qthread.cpp:498 #8 0x7f5ec5482d05 in QThreadPrivate::start (arg=0x2293cc0) at thread/qthread_unix.cpp:331 #9 0x7f5ebf90eefc in start_thread (arg=0x7f5eacf3e700) at pthread_create.c:304 #10 0x7f5ec4e3889d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x in ?? () Thread 3 (Thread 0x7f5e5fad3700 (LWP 18571)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 #1 0x7f5ec548311e in wait (time=3, this=0x31bcfe0) at thread/qwaitcondition_unix.cpp:86 #2 QWaitCondition::wait (this=, mutex=0x35e8250, time=3) at thread/qwaitcondition_unix.cpp:160 #3 0x7f5ec547781f in QThreadPoolThread::run (this=0x2db06f0) at concurrent/qthreadpool.cpp:140 #4 0x7f5ec5482d05 in QThreadPrivate::start (arg=0x2db06f0) at thread/qthread_unix.cpp:331 #5 0x7f5ebf90eefc in start_thread (arg=0x7f5e5fad3700) at pthread_create.c:304 #6 0x7f5ec4e3889d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #7 0x in ?? () Thread 2 (Thread 0x7f5e51b2d700 (LWP 18583)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 #1 0x7f5ec548311e in wait (time=3, this=0x2d5a4e0) at thread/qwaitcondition_unix.cpp:86 #2 QWaitCondition::wait (this=, mutex=0x2d5a410, time=3) at thread/qwaitcondition_unix.cpp:160 #3 0x7f5ec547781f in QThreadPoolThread::run (this=0x2d6c8e0) at concurrent/qthreadpool.cpp:140 #4 0x7f5ec5482d05 in QThreadPrivate::start (arg=0x2d6c8e0) at thread/qthread_unix.cpp:331 #5 0x7f5ebf90eefc in start_thread (arg=0x7f5e51b2d700) at pthread_create.c:304 #6 0x7f5ec4e3889d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #7 0x in ?? () Thread 1 (Thread 0x7f5ec78c47a0 (LWP 16648)): [KCrash Handler] #6 deref (this=0x20) at /usr/include/qt4/QtCore/qatomic_x86_64.h:133 #7 ~QString (this=0x8a86ab0, __in_chrg=) at /usr/include/qt4/QtCore/qstring.h:883 #8 ~AddrSpec (this=0x8a86aa8, __in_chrg=) at ../../kmime/kmime_header_parsing.h:54 #9 ~Mailbox (this=0x8a86aa0, __in_chrg=) at ../../kmime/kmime_header_parsing.h:68 #10 node_destruct (to=0x7bb95f8, from=0x7bb95f8, this=) at /usr/include/qt4/QtCore/qlist.h:418 #11 QList::free (data=0x7bb95e0, this=) at /usr/include/qt4/QtCore/qlist.h:744 #12 0x7f5ebc1062a8 in ~Address (this=0x3638ca0, __in_chrg=) at
[Bug 236298] Akonadi displays error on start up
https://bugs.kde.org/show_bug.cgi?id=236298 Matthias Kretz changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||kr...@kde.org Ever Confirmed|0 |1 --- Comment #2 from Matthias Kretz 2010-05-29 11:14:23 --- I also get the "No resource agents found." issue sometimes. It says "The following paths have been searched: '/usr/share/akonadi/agents /usr/share/akonadi/agents'." and I wondered whether it searches '/usr/share/akonadi/agents /usr/share/akonadi/agents' or '/usr/share/akonadi/agents' twice. The former would obviously fail... It seems to be the exact same issue as the original report and it is very annoying because Akonadi in principle is working correctly. I'm also on Kubuntu. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- 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
[Bug 217725] New: attaching a vcard does not remove (potentially sensitive) categories
https://bugs.kde.org/show_bug.cgi?id=217725 Summary: attaching a vcard does not remove (potentially sensitive) categories Product: kmail Version: unspecified Platform: Ubuntu Packages OS/Version: Linux Status: NEW Severity: normal Priority: NOR Component: general AssignedTo: kdepim-bugs@kde.org ReportedBy: kr...@kde.org Version:(using KDE 4.3.2) OS:Linux Installed from:Ubuntu Packages How to reproduce: - Start a new mail - drag a contact from KAddressbook and drop it on the composer - send - receiver imports the vcard into his address book Result: The categories that were used for the contact by the sender are all stored in the vcard and merged into the receivers address book. Expected Result: KMail/KAddressbook removes the categories when attaching the vcard. Possibly the drop could open a menu (like when dropping files, asking for move/copy/link) asking what should be removed/attached. Rationale: While I might be "Family" for my wife, I'm not "Family" for my coworker. Even worse, there are good uses for category names that might be sensitive information. This should never be shared so easily. Also KMail does not show the category names are stored in the vcard when looking at it! -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
