[kmail2] [Bug 487049] There is no way to order the account list in the main window of kmail
https://bugs.kde.org/show_bug.cgi?id=487049 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #1 from Martin Steigerwald --- In KMail 5.22.3 (22.12.3) there is: Its in Settings / Account / Receiver (or something like that, translated from German) below the account list: "Edit account order". -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 355342] composer mangles mail text on forwarding or edit as new
https://bugs.kde.org/show_bug.cgi?id=355342 Martin Steigerwald changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Martin Steigerwald --- Closing. I am using Evolution instead of KMail for the setup where this issue happened. -- You are receiving this mail because: You are the assignee for the bug.
[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 --- Comment #18 from Martin Steigerwald --- Thank you David! I really appreciate it! -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage
https://bugs.kde.org/show_bug.cgi?id=481024 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de -- You are receiving this mail because: You are the assignee for the bug.
[Reminder Daemon] [Bug 453298] kalendarac: Notifications miss option to remind later with other time duration than 5 minutes
https://bugs.kde.org/show_bug.cgi?id=453298 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #3 from Martin Steigerwald --- Agreed, I missed several birthday greetings due to this already. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 389608] akonadictl fsck: offer to fix duplicate items
https://bugs.kde.org/show_bug.cgi?id=389608 Martin Steigerwald changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #6 from Martin Steigerwald --- "akonadictl fsck" still does not offer to repair duplicate RIDs or help the user to fix it themselves. However I did not see this issue in the recent years. So works for me. -- You are receiving this mail because: You are the assignee for the bug.
[akregator] [Bug 387550] According to panopticlick 3.0 test does not protect against trackers
https://bugs.kde.org/show_bug.cgi?id=387550 Martin Steigerwald changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME --- Comment #4 from Martin Steigerwald --- Testing for Konqueror shows considerable improvement¹. And AFAIK meanwhile it blocks Javascript anyway. Thus closing. https://bugs.kde.org/show_bug.cgi?id=387549#c4 There is still room for improvement, but as for limited use its good enough I'd say. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 Martin Steigerwald changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REOPENED --- Comment #18 from Martin Steigerwald --- I still see KMail crashing from time to time during filtering mails in a Maildir resource received by POP3 resource. KMail 5.21.0 (22.08.0) on Devuan Ceres with KDE Plasma 5.25.5, KF5 5.98.0 and Qt 5.15.6. I did not verify whether the back trace is similar as I saw bug reports regarding KDEPIM sitting in Bugzilla for ages and I am currently not convinced to spend time on it. I took a long time to provide quite a lot of accurate bug reports with a lot of details often with little result. However… if there is a developer willing to look into this bug then I am willing to invest time to create another back trace and answer further questions. (No offense meant. The situation is as it is.) -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 457262] Generate privacy-aware Message-Ids
https://bugs.kde.org/show_bug.cgi?id=457262 --- Comment #1 from Martin Steigerwald --- Also see: Bug 457263 - Configure Message-Id per identity or SMTP resource. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 457263] Configure Message-Id per identity or SMTP resource
https://bugs.kde.org/show_bug.cgi?id=457263 Martin Steigerwald changed: What|Removed |Added Severity|normal |wishlist -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 457263] New: Configure Message-Id per identity or SMTP resource
https://bugs.kde.org/show_bug.cgi?id=457263 Bug ID: 457263 Summary: Configure Message-Id per identity or SMTP resource Product: kmail2 Version: 5.20.3 Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: mar...@lichtvoll.de Target Milestone: --- One can configure the suffix for a custom Message-Id in Configure->Composer->Header->Use custom message-Id suffix. However that is a global setting for all identities and all SMTP resources. That is not optimal, in case you have multiple mail setups using different domains. You'd need to use a fantasy name for all domain then. But this then still could make it possible to find out that mails from different mail accounts are created by the same client. This bug could also be in a different product/component like Akonadi / Mail dispatcher agent, but it really depends on where this configuration option would best be implemented. Also see: Bug 457262 - Generate privacy-aware Message-Ids -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 457262] New: Generate privacy-aware Message-Ids
https://bugs.kde.org/show_bug.cgi?id=457262 Bug ID: 457262 Summary: Generate privacy-aware Message-Ids Product: kmail2 Version: 5.20.3 Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: mar...@lichtvoll.de Target Milestone: --- KMail by default uses the local host name as suffix for Message-Id. This has two downsides: 1. It reveals the local hostname even in case a privacy aware mail server removed the first Received: header. 2. It is not guaranteed to be unique. I'd not mind the second disadvantage as there is no easy way to make the second part unique to begin with, unless you generate some kind of UUID for that. But doing so might have other privacy implications. A good default might be to use the domain name from an SMTP transport. Or the domain part of the mail address in an identity. This bug could also be in a different product/component like Akonadi / Mail dispatcher agent, but it really depends on where this configuration option would best be implemented. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 443095] New: Moving mails to a different folder is very slow
https://bugs.kde.org/show_bug.cgi?id=443095 Bug ID: 443095 Summary: Moving mails to a different folder is very slow Product: Akonadi Version: 5.18.1 Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Maildir Resource Assignee: kdepim-bugs@kde.org Reporter: mar...@lichtvoll.de Target Milestone: --- SUMMARY I moved 13647 from one folder to another. It took a lot of time. I'd say at least 5 minutes, but I'd say it was longer than that. During that time KMail stalled on Akonadi and thus did not display any mail. It was basically unusable during that time. STEPS TO REPRODUCE 1. Move 1 mails from one folder to another 2. Wait 3. Wait 4. Wait 5. … OBSERVED RESULT Moving those mails took a lot of time. In the end I monitored how many mails it adds to the destination maildir folder each 10 seconds and got this: % while true; do find -type f | wc -l ; sleep 10 ; done 12426 12645 12936 13216 13445 13609 13647 13647 13647 13647 So it did about 200-300 mails every 10 seconds. Or 20-30 mails a second. This makes about 454 seconds or 7 minutes for and 34 seconds for moving all of the mails, in case it started moving mails immediately and it would reach 300 mails a second consistently. I did not measure the exact total time, but I believe it was more like 10 minutes or more. EXPECTED RESULT Those mails are basically moved within a few seconds. This is a ThinkPad T14 AMD Gen 1 with AMD Ryzen 7 PRO 4750U 8 core processor with hyperthreading, 32 GB RAM and 2 TB Samsung 980 Pro SSD. This hardware really gives no reason to be slow with such a kind of operation. During the move operation consequently neither the CPU, not even a single core, nor the SSD was fully utilized. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.21.5 on Devuan Ceres (aka Debian Sid without Systemd, I use runit instead) KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.86 Qt Version: 5.15.2 Linux Kernel 5.14.7, self compiled. I am using PostgreSQL backend. -- You are receiving this mail because: You are the assignee for the bug.
[akregator] [Bug 361588] Text of articles from certain websites displayed way too small
https://bugs.kde.org/show_bug.cgi?id=361588 Martin Steigerwald changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #8 from Martin Steigerwald --- Thanks for checking. I do not use the internal Qt WebEngine based webbrowser for displaying web pages anymore as I think I can not protect it well enough against any tracking and spying attempts of Google, Facebook and Co. So I told Akregator to open articles in my hardened Firefox browser setup a long time ago. Thus closing. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 424231] Logging in to a enterprise managed EWS server "needs" MS intune
https://bugs.kde.org/show_bug.cgi?id=424231 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #6 from Martin Steigerwald --- I think it is fair enough to set this report to confirmed, after you dug out the source code location. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 424231] Logging in to a enterprise managed EWS server "needs" MS intune
https://bugs.kde.org/show_bug.cgi?id=424231 --- Comment #5 from Martin Steigerwald --- Good catch, Victor, read the "Bad bad Microsoft..." comment for a reasoning behind this. https://invent.kde.org/pim/kdepim-runtime/-/blob/master/resources/ews/ewsclient/auth/ewsoauth.cpp If you like to dig a little deeper and make it easier for Krzysztof to fix this issue, I suggest you dig up the evolution-ews source code and look there what they use. https://gitlab.gnome.org/GNOME/evolution-ews Krzysztof, maybe it would be good to allow users to override this user agent string, too? In case Microsoft has a new idea on locking out users in the future? As for the compilation dependencies, if you use kdesrc-build, I think you can tell it to compile everything else that is needed in a newer version as well. But maybe you also just have to install the -dev / -devel package for the library in question, in case you did not already do so. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 424231] Logging in to a enterprise managed EWS server "needs" MS intune
https://bugs.kde.org/show_bug.cgi?id=424231 --- Comment #3 from Martin Steigerwald --- Thank you. That is an important clarification. If your company Intune policy allows the use of Linux clients and the login works with Evolution EWS, then it indeed appears to be an issue with Akonadi EWS. Did you try different user agent strings (see advanced settings for Akonadi EWS)? Maybe use the same that works in Evolution EWS. For the login thing, Qt WebEngine might be used, though, so it may be related to that, and the user agent setting may not make any difference. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 424231] Logging in to a enterprise managed EWS server "needs" MS intune
https://bugs.kde.org/show_bug.cgi?id=424231 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #1 from Martin Steigerwald --- Thank for your the bug report. I do not think Akonadi EWS can do anything about it. That is just how Microsoft Intune works¹. Unless your employer is willing to grant to an exception, I'd say you are locked out. Leaving it open for Krzysztof, the developer of Akonadi EWS, to check on this. [1] That is not to say that I agree with the approach behind Microsoft Intune. It is fundamentally incompatible with free software as far as I understood. Consequently as far as I know it only supports Windows, Mac OS X and Android as platforms. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 Martin Steigerwald changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REOPENED|NEEDSINFO --- Comment #23 from Martin Steigerwald --- Toni, I am not going to do a git bisect between Qt 5.12 and Qt 5.14 – it would take a long, long, long time on this quite a bit older laptop. But maybe someone else is willing to or… has an idea what commit it might be. But I reopened the bug and set it to "NEEDSINFO". So if someone is willing to identify the git commit or has an idea which one it could be already… go ahead. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 Martin Steigerwald changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422624] Akonadi does full rescan on every change in maildir
https://bugs.kde.org/show_bug.cgi?id=422624 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Martin Steigerwald --- Lars, okay. I believe the "does a full rescan" issue is still there, but that like with bug #422336 with Qt 5.14 that "full rescan" is much faster again. Anyway, closing on your request. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 Martin Steigerwald changed: What|Removed |Added Resolution|--- |WORKSFORME Status|CONFIRMED |RESOLVED --- Comment #20 from Martin Steigerwald --- (In reply to phil-deb1.mer...@laposte.net from comment #19) > Since Qt 5.14.2 arrived in the unstable version of Debian with a > modification of Akonadi the problem has disappeared. Thank you so much. For > me I consider that the Bug is resolved. I can confirm that akonadi_maildir_resource is much faster again as well. I wasn't sure initial, but I just tested switching between folders and it is much faster again. I don't know that fixed it but it maybe that Akonadi 20.04 and Qt 5.12 did not like each other. Jonas, can you confirm that IMAP resource is still slow with Qt 5.14? If so, I suggest this to be a different bug. Anyway I am closing as RESOLVED / WORKSFORME now as… I have no idea what fixed it. If anyone still has this issue, with maildir resource, please speak up and I open it again. Confirm that you are running on Qt 5.14 though. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #18 from Martin Steigerwald --- (In reply to Jonas Schäfer from comment #17) > I would like to confirm the imap resource problem being similar, but I don’t > know which specific perf invocation produces output like the one shown above. Marc, could you post the perf command line you used for the analysis in comment #14? It is more detailed than what I used (and do not remember right now). -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #16 from Martin Steigerwald --- (In reply to Sander van Grieken from comment #15) > I'm not so sure the root cause is the maildir resource. I'm experiencing > major slowdowns using imap resource as well. Maybe. However for now I suggest you open a different bug report about that, unless you can verify the following: Does akonadi_imap_resource also produce 100% cpu usage, does it spin in the same areas (see perf output in the comments)? If not, please open a separate bug report. Feel free to add a link to your new bug report in a comment here. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 414178] Deleting all contacts deletes entire /home/user/
https://bugs.kde.org/show_bug.cgi?id=414178 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO CC||mar...@lichtvoll.de --- Comment #5 from Martin Steigerwald --- Dear Anselm, thank you for that important bug report. Does the fix from comment #1 by Volker Krause actually fix the issue? If its still not fixed please reply and set to REPORTED again, if you cannot set this, let me know and I will do it. Also please set the version you tested with, preferably 5.14.x aka 20.04 or at least 19.12, you see the version by using akonadictl --version IMPORTANT: Please make sure that you test this with a user you created for testing to avoid loosing valuable data. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422490] maildir resource gets stuck on synchronizing a folder with 72 messages
https://bugs.kde.org/show_bug.cgi?id=422490 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #2 from Martin Steigerwald --- Dear Philippe. Thanks for confirming. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336
--- Comment #13 from Martin Steigerwald ---
Strace output when maildir resources takes ages to complete a synchronization:
[pid 7806] poll([{fd=5, events=POLLIN}, {fd=13, events=POLLIN}], 2, 55
[pid 7815] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 7806] <... poll resumed>) = 1 ([{fd=5, revents=POLLIN}])
[pid 7806] read(5, "\1\0\0\0\0\0\0\0", 16) = 8
[pid 7806] poll([{fd=5, events=POLLIN}, {fd=13, events=POLLIN}], 2, 50
[pid 7815] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 7806] <... poll resumed>) = 1 ([{fd=5, revents=POLLIN}])
[pid 7806] read(5, "\1\0\0\0\0\0\0\0", 16) = 8
[pid 7806] poll([{fd=5, events=POLLIN}, {fd=13, events=POLLIN}], 2, 46
[pid 7815] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 7806] <... poll resumed>) = 1 ([{fd=5, revents=POLLIN}])
[pid 7806] read(5, "\1\0\0\0\0\0\0\0", 16) = 8
[pid 7806] poll([{fd=5, events=POLLIN}, {fd=13, events=POLLIN}], 2, 41
[pid 7815] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 7806] <... poll resumed>) = 1 ([{fd=5, revents=POLLIN}])
[pid 7806] read(5, "\1\0\0\0\0\0\0\0", 16) = 8
[pid 7806] poll([{fd=5, events=POLLIN}, {fd=13, events=POLLIN}], 2, 37
[pid 7815] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 7806] <... poll resumed>) = 1 ([{fd=5, revents=POLLIN}])
[pid 7806] read(5, "\1\0\0\0\0\0\0\0", 16) = 8
[pid 7806] poll([{fd=5, events=POLLIN}, {fd=13, events=POLLIN}], 2, 31
[pid 7815] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 7806] <... poll resumed>) = 1 ([{fd=5, revents=POLLIN}])
[pid 7806] read(5, "\1\0\0\0\0\0\0\0", 16) = 8
[pid 7806] poll([{fd=5, events=POLLIN}, {fd=13, events=POLLIN}], 2,
26^Cstrace: Process 7806 detached
It goes on like that in rapid succession. 10 second statistic:
% timeout 10 strace -cp 7806
strace: Process 7806 attached
strace: Process 7806 detached
% time seconds usecs/call callserrors syscall
-- --- --- - -
75,590,052635 32 1618 poll
24,250,016883 11 1531 read
0,160,000111 424 futex
0,000,00 0 1 restart_syscall
-- --- --- - -
100.000,069629 3174 total
[…]/proc/7806> ls -l fd/5
lrwx-- 1 martin martin 64 Jun 9 13:57 fd/5 -> 'anon_inode:[eventfd]'
[…]/proc/7806> ls -l fd/13
lr-x-- 1 martin martin 64 Jun 9 13:57 fd/13 -> anon_inode:inotify
--
You are receiving this mail because:
You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #12 from Martin Steigerwald --- See also: Bug 422624 - Akonadi does full rescan on every change in maildir as well as reopened Bug 334209 - synchronizes folder contents during runtime needlessly when switching between different folders -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422624] Akonadi does full rescan on every change in maildir
https://bugs.kde.org/show_bug.cgi?id=422624 --- Comment #2 from Martin Steigerwald --- (In reply to Martin Steigerwald from comment #1) > Means: It did this needless synchronization before, bug before the but > performance regression in Akonadi 5.14.1 (aka 20.04) it was much quicker and > thus did not block out KMail so long. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 334209] synchronizes folder contents during runtime needlessly when switching between different folders
https://bugs.kde.org/show_bug.cgi?id=334209 Martin Steigerwald changed: What|Removed |Added Version|GIT (master)|5.14.1 Status|RESOLVED|REOPENED Ever confirmed|0 |1 Platform|unspecified |Debian unstable Resolution|WORKSFORME |--- Summary|synchronizes folder |synchronizes folder |contents during runtime |contents during runtime |needlessly |needlessly when switching ||between different folders --- Comment #3 from Martin Steigerwald --- This is again happening. Maybe it never stopped with 16.04, but after the serious performance regression between Akonadi 19.08 and Akonadi 5.14.1 (20.04)¹ it is again much more noticable. [1] Bug 422336 - kmail: the access and reading of the received messages is often very slow -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422624] Akonadi does full rescan on every change in maildir
https://bugs.kde.org/show_bug.cgi?id=422624 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #1 from Martin Steigerwald --- This is likely a duplicate to Bug 422336 - kmail: the access and reading of the received messages is often very slow in combination with Bug 334209 - synchronizes folder contents during runtime needlessly and Bug 334216 - synchronizes folder with filesystem after downloading and filtering mails needlessly Means: It did this needless synchronization before, bug before the performance regression in Akonadi 5.14.1 (aka 20.04) it was much quicker and thus did not block out KMail so long. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #11 from Martin Steigerwald --- (In reply to Martin Steigerwald from comment #10) > Marc, thank you a lot for your analysis in comment #2. I just noticed it > now. I bet it can be valuable help for the developers to pinpoint the issue. I can confirm your finding with perf top: Samples Overhead Shared Object Symbol 65,66% libQt5Core.so.5.12.5 [.] QMetaObjectPrivate::disconnect 5,87% [kernel] [k] 0x81737191 2,07% libQt5Core.so.5.12.5 [.] QMetaObject::activate 1,58% i965_dri.so [.] linear_to_ytiled_faster 0,66% libKF5MessageList.so.5.14.1.abi1 [.] MessageList::Core::Item::parent 0,59% libQt5WebEngineCore.so.5.12.5 [.] exec_ops 0,48% libQt5Gui.so.5.12.5 [.] qt_alphamapblit_argb32 0,39% libKF5MessageList.so.5.14.1.abi1 [.] MessageList::Core::Item::indexOfChildItem 0,35% libQt5Gui.so.5.12.5 [.] qt_memfill32 0,31% libKF5MessageList.so.5.14.1.abi1 [.] MessageList::Core::Item::type 0,25% libc-2.30.so [.] _int_malloc Samples Overhead Shared Object Symbol 72,54% libQt5Core.so.5.12.5 [.] QMetaObjectPrivate::disconnect 4,87% [kernel] [k] 0x81737191 1,72% libQt5Core.so.5.12.5 [.] QMetaObject::activate 0,74% libKF5MessageList.so.5.14.1.abi1 [.] MessageList::Core::Item::parent 0,56% libKF5MessageList.so.5.14.1.abi1 [.] MessageList::Core::Item::indexOfChildItem 0,52% perf_5.6 [.] 0x0033fe21 0,48% perf_5.6 [.] 0x00275703 0,36% i965_dri.so[.] linear_to_ytiled_faster 0,30% libQt5Core.so.5.12.5 [.] QAbstractItemModelPrivate::rowsAboutToBeInserted 0,30% libQt5Core.so.5.12.5 [.] QAbstractItemModelPrivate::rowsAboutToBeRemoved 0,23% libQt5Core.so.5.12.5 [.] bm_find -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #10 from Martin Steigerwald --- Marc, thank you a lot for your analysis in comment #2. I just noticed it now. I bet it can be valuable help for the developers to pinpoint the issue. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #9 from Martin Steigerwald --- An awkward work-around demonstrates that it really is Akonadi maildir resource. If I terminate the akonadi_maildir_resource process KMail almost immediately becomes responsive again. But if I do this for more than three times then Akonadi considers the resource to be broken and would not start it anymore. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #8 from Martin Steigerwald --- (In reply to Martin Steigerwald from comment #7) > With a folder with about 30500 it just got that back that KMail gave up > waiting after some minutes: it just got that bad -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #7 from Martin Steigerwald --- With a folder with about 30500 it just got that back that KMail gave up waiting after some minutes: "Unable to fetch item from backend (collection -1): Unable to contact resource." Why "-1"? I have no clue. So or so… this is an error message an user should never ever see, cause its incomprehensible and the user also cannot do anything about it. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x
https://bugs.kde.org/show_bug.cgi?id=338571 --- Comment #54 from Martin Steigerwald --- Tore, thank you again for your recent findings. Just to let you know: I was not doubting it. In my experience Akonadi based KMail with IMAP never really worked with folders with more than maybe 1-2 mails. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 --- Comment #6 from Martin Steigerwald --- - Open a folder with just about 13000 mails - Click on it for the first time in a KMail/Akonadi session or after a while you used it last again - Wait for one minute for Akonadi to deliver the payload of a mail I like to reply to to KMail This is unbearable. I do not remember it ever having been that bad. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x
https://bugs.kde.org/show_bug.cgi?id=338571 Martin Steigerwald changed: What|Removed |Added Version|5.5.2 |5.14.1 --- Comment #53 from Martin Steigerwald --- Thank you, Tore. I updated the version number in the bug report from 5.5.2 to 5.14.1. As for the initial size requirement, I think that is just the MariaDB database with InnoDB logfiles. AFAIR it uses 2x64 MiB InnoDB logfiles already. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x
https://bugs.kde.org/show_bug.cgi?id=338571 --- Comment #48 from Martin Steigerwald --- Gunter, sorry for spelling your name wrong. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x
https://bugs.kde.org/show_bug.cgi?id=338571 Martin Steigerwald changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|CONFIRMED |NEEDSINFO --- Comment #47 from Martin Steigerwald --- Tore, Gunther or someone else who commented here: Could you please check whether you still have those performance issues you reported there with KDEPIM/Akonadi 20.04? If so, it might be good to report it in a new bug since – with my contribution unfortunately, this bug report has so many comments that it may be difficult to make sense out of it for a developer. If so, it would be good if you could provide some performance data again. I may check using the anonymous IMAP from IETF myself if I manage to take time for that. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Akonadi] [Bug 367892] During folder synchronisation Akonadi blocks out other operations like deleting or viewing mails
https://bugs.kde.org/show_bug.cgi?id=367892 --- Comment #7 from Martin Steigerwald --- (In reply to Erik Quaeghebeur from comment #6) > (In reply to Martin Steigerwald from comment #4) > > 1) Why does it synchronize the folder anyway when I hit delete the folder > > mail list several times? To make sure the IMAP server has done its work? > If that would be the case, it would be doing needless work: the IMAP server > will provide a response to the deletion (expunge?) request and that should > be enough (unless of course the server responds with an error). I do not have a KMail/Akonadi setup with a large IMAP folder at the moment. But I tested it again with POP3. Just hitting delete inside the mail list of the trash folder which had new spam and KDE CI messages in it. After I hit about five times, it was displaying that it synchronized the trash folder although Akonadi should have been aware of what it deleted and what it did not delete and the BTRFS filesystem certainly did not say "Hey, I am not going to delete that file just to annoy you". I could temporarily setup such an IMAP account again tough. As for IMAP I heard that some of the folder synchronization is done for two reasons: 1) Sometimes the connection to the IMAP server may drop or be interrupted. But I am pretty certainly that this was not the case here. It was with a Dovecot based IMAP server that is even hosted in the same city and only serves me and a few friends. 2) It can be that some other IMAP mail client does something at the same time. But then not hitting the delete key several time should trigger a re-sync. Basically it would suffice to trigger a re-sync when I click on the folder to see its contents and probably there has been no re-sync after some time. Ideally Akonadi would use some IMAP thing to find out whether there have been changes to begin with, but I am not sure whether the IMAP protocol allows for that. In any way I never saw another IMAP client behaving in such a way and I never saw another IMAP client *blocking* out users requests for the payload of a mail during a re-sync. Either they re-sync or not, but if they do they do it in a much less intrusive way. But again this is another issue I reported (bug #367892). These two bugs combined for local mail access with the recent regression in maildir resource folder synchronization speed (bug #422336) and reliability (bug #422490) make a "wait for Akonadi" game out of KMail. Which is a pity, cause KMail is an awesome mail client. > What I'm wondering is whether KMail can be involved here: perhaps KMail > requests a synchronization? I doubt it. I think this is all happening within Akonadi. But I don't know for sure. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422490] maildir resource gets stuck on synchronizing a folder with 72 messages
https://bugs.kde.org/show_bug.cgi?id=422490 Martin Steigerwald changed: What|Removed |Added Summary|maildir gets stuck on |maildir resource gets stuck |synchronizing a folder with |on synchronizing a folder |72 messages |with 72 messages -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 334216] synchronizes folder with filesystem after downloading and filtering mails needlessly
https://bugs.kde.org/show_bug.cgi?id=334216 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 334216] synchronizes folder with filesystem after downloading and filtering mails needlessly
https://bugs.kde.org/show_bug.cgi?id=334216 Martin Steigerwald changed: What|Removed |Added Version|GIT (master)|5.14.1 Platform|unspecified |Debian unstable --- Comment #3 from Martin Steigerwald --- This still happens with Akonadi 5.14.1 (20.04) -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 367892] During folder synchronisation Akonadi blocks out other operations like deleting or viewing mails
https://bugs.kde.org/show_bug.cgi?id=367892 Martin Steigerwald changed: What|Removed |Added Version|5.2.0 |5.14.1 --- Comment #5 from Martin Steigerwald --- This still happens with Akonadi 5.14.1 (20.04) -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow
https://bugs.kde.org/show_bug.cgi?id=422336 Martin Steigerwald changed: What|Removed |Added Component|general |Maildir Resource Product|kmail2 |Akonadi Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||mar...@lichtvoll.de --- Comment #5 from Martin Steigerwald --- Reassigning to Akonadi. I can not select maildir resource at the moment, I bet I first need to save the comment and then I will reassign to maildir resource. That is what I believe where the issue happens. I confirm this. I am using KDEPIM 20.04 with KMail and Akonadi 5.14.1 on Debian Sid with PostgreSQL database. OBSERVED RESULT Compared to KDEPIM / Akonadi 19.08 synchronizing a mail folder even with just a few thousand mails takes much, much longer. It easily takes a minute or more during which Akonadi does not respond to KMail requesting the payload of a mail anymore. This needs to the "Retrieving folder contents" when clicking on a mail Akonadi did not retrieve recently before. During the synchronization it consumes 100% of one Intel Sandybridge Mobile i5 CPU core for a minute or longer. I checked once with strace and it was polling several dozens if not more times a second on an eventfd. If you have some instructions I can try to find out more about what the maildir resource is doing at during those slow synchronization operations. EXPECTED RESULT 1. Akonadi maildir resource works as fast as with KDEPIM / Akonadi 19.08 before. 2. Akonadi never ever blocks an immediate user request for displaying a mail while performing a background task but this I already reported in: [Akonadi] [Bug 367892] New: During folder synchronization Akonadi blocks out other operations like deleting or viewing mails. 3. It does not needlessly synchronize local folders. For local mails during runtime Akonadi as already an inotify watch on every folder. Yet it synchronizes the same folders several times during Akonadi session even *tough* Akonadi is *the only* one writing to it. I also reported this one already in: [Akonadi] [Bug 334216] New: synchronizes folder with filesystem after downloading and filtering mails needlessly -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 422490] New: maildir gets stuck on synchronizing a folder with 72 messages
https://bugs.kde.org/show_bug.cgi?id=422490
Bug ID: 422490
Summary: maildir gets stuck on synchronizing a folder with 72
messages
Product: Akonadi
Version: 5.14.1
Platform: Debian unstable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Maildir Resource
Assignee: kdepim-bugs@kde.org
Reporter: mar...@lichtvoll.de
Target Milestone: ---
Created attachment 129077
--> https://bugs.kde.org/attachment.cgi?id=129077=edit
KMail reporting maildir synchronizing trash folder
This is with KDEPIM/Akonadi 20.04 on Debian Sid, using PostgreSQL 12. I don't
think I saw this with KDEPIM/Akonadi 19.08.
SUMMARY
Synchronizing a maildir folder even with just a few thousand messages or in
this case with about a hundred messages can get stuck. During this time Akonadi
does not react to any request of KMail to get the payload of a mail I click on.
Which basically makes KMail mostly unusable as it won't display any mails
Akonadi did not retrieve the payload for shortly ago.
Often akonadi_maildir_resource consumes about 100% of one core (Intel
Sandybridge i5) for a minute or longer. In case it gets stuck, CPU usage drops.
This is about the case where it gets stuck.
STEPS TO REPRODUCE
1. Use KMail and Akonadi with some POP3 mail accounts delivering.
2. Retrieve new mails or even just switch to a folder not synchronized
recently.
OBSERVED RESULT
akonadi_maildir_resource takes much, much longer than with Akonadi 19.08 or
even gets stuck. In the case for this report it gets stuck.
Here is an strace and it just seems to poll on an inotify watch and does not
seem to do much of anything else.
% strace -ffp 4012
strace: Process 4012 attached with 4 threads
[pid 4084] restart_syscall(<... resuming interrupted read ...>
[pid 4072] restart_syscall(<... resuming interrupted read ...>
[pid 4051] restart_syscall(<... resuming interrupted read ...>
[pid 4012] restart_syscall(<... resuming interrupted read ...>
[pid 4051] <... restart_syscall resumed>) = 1
[pid 4051] recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="U\2=\26d\230\340\1\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0
\1\4\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) =
32
[pid 4051] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 4012] <... restart_syscall resumed>) = 1
[pid 4012] read(5,
[pid 4051] poll([{fd=3, events=POLLIN}], 1, -1
[pid 4012] <... read resumed>"\1\0\0\0\0\0\0\0", 16) = 8
[pid 4012] poll([{fd=5, events=POLLIN}, {fd=11, events=POLLIN}], 2, 1703
[pid 4051] <... poll resumed>) = 1 ([{fd=3, revents=POLLIN}])
[pid 4051] recvmsg(3, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="U\2=\26\304\230\340\1\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\1\5\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) =
32
[pid 4051] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 4051] poll([{fd=3, events=POLLIN}], 1, -1
[pid 4012] <... poll resumed>) = 1 ([{fd=5, revents=POLLIN}])
[pid 4012] read(5, "\1\0\0\0\0\0\0\0", 16) = 8
It is an inotify watch:
% /proc/4012/fd> ls -l 11
lr-x-- 1 martin martin 64 Jun 5 17:30 11 -> anon_inode:inotify
EXPECTED RESULT
Maildir resource does not get stuck.
Also… Akonadi never ever blocks requests of KMail for the payload of a mail.
Cause then the user waits. But this is another issue and I believe it has been
reported already. Maybe it was me reporting it quite some time ago. A
background task *never ever* is more important than what the user wants now.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian Unstable
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.70
Qt Version: 5.12
ADDITIONAL INFORMATION
The bug about akonadi_maildir_resource being slow is bug #422336. I will add
some information there as well.
--
You are receiving this mail because:
You are the assignee for the bug.
[Akonadi] [Bug 412629] Akonadi refuses to start after upgrade to PostgreSQL 12: column "version" of relation "schemaversiontable" already exists
https://bugs.kde.org/show_bug.cgi?id=412629 --- Comment #5 from Martin Steigerwald --- Does the fix in libqt5sql5-psql: basic support postgresql-12 https://bugs.debian.org/941763 fix this issue or not? Or in other words: Has this been fixed or is it still an issue? I am asking, cause this bug report is still open. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 412629] Akonadi refuses to start after upgrade to PostgreSQL 12: column "version" of relation "schemaversiontable" already exists
https://bugs.kde.org/show_bug.cgi?id=412629 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 403903] does not respect org.kde.pim.ews.client: a:ErrorServerBusy: The server cannot service this request right now. Try again later.
https://bugs.kde.org/show_bug.cgi?id=403903 --- Comment #16 from Martin Steigerwald --- Continuing the work when Office 365 becomes available again is important. However I wonder whether it would be possible to avoid ErrorServerBusy. But well, as long as Microsoft does not tell how much load they accept, it may just be that. Hitting ErrorServerBusy, pausing, continuing after service is available again, hitting ErrorServerBusy again. I am currently using Evolution EWS since Akonadi EWS does not work reliable enough with my Office 365 mail account and while I see that it retries an operation from time to time it does not become stuck. So it might be good to look there how they handle this situation. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 343114] gets stuck on one request that times out, kmail and akonadiconsole do not display any mail payloads anymore, stuck waiting
https://bugs.kde.org/show_bug.cgi?id=343114 --- Comment #9 from Martin Steigerwald --- David, Akonadi 5.7.3 is quite old, from KDEPIM 18.04 from April 2018 if I got this right. I am still not clear whether it is really the same bug, as I for me the original issue did not happen anymore since quite a while and I just forgot to close the bug report. Please consider to test with a newer KDEPIM/Akonadi version. You may use KDE Neon ISO images in a virtual machine for that. In any case I suggest you report your issue as a new bug, cause this bug IMHO is quite old, got quite convoluted and difficult for developers to make sense of. In that case I'd close this bug. Also if just replying to the last comment it is not necessary to quote and top-post. Short and precise is key for developers to act on bugs, which I did not adhere to back then either. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Akonadi] [Bug 343114] gets stuck on one request that times out, kmail and akonadiconsole do not display any mail payloads anymore, stuck waiting
https://bugs.kde.org/show_bug.cgi?id=343114 --- Comment #7 from Martin Steigerwald --- Dear David, thanks for adding your update to the bug report. However, if you change the version please also really set a new version, instead of setting 'unspecified'. Do 'akonadictl --version' and specify the version you see in the bug report. If the version is not in the selection, please select the closest one and put the output of the command in a comment. Please do not expect upstream developers to know or dig out what version OpenSUSE LEAP 15.0 would contain. Also preferably use OpenSUSE LEAP 15.1 to test with the newest version available. Additionally for me "akonadictl stop" and "akonadictl start" worked in order to bring Akonadi back into a working state. So your issue may even be something completely different. It would be beneficial to at least gather some console output to see whether you are really having the same issue. Especially whether you see the same: request for item 1669405 "902" failed: "Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." kind of messages. For that to see start kmail from a terminal. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[kmail2] [Bug 341909] Reply and Print time is in UTC, not in locale
https://bugs.kde.org/show_bug.cgi?id=341909 --- Comment #19 from Martin Steigerwald --- I am also seeing local time. With KDEPIM/Akonadi 18.08 on Debian Sid. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 388036] Include support for autocrypt
https://bugs.kde.org/show_bug.cgi?id=388036 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||mar...@lichtvoll.de --- Comment #5 from Martin Steigerwald --- There is already a Phabricator task tagged for KDE Privacy Goal about this. Thus confirming. Autocrypt support for kmail https://phabricator.kde.org/T8408 This is a junior job suitable for new contributors. So if you like to help, get in touch with KDEPIM team. Otherwise please have patience until someone else implements it. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 409122] Akonadi sometimes doesn't send email (GMail)
https://bugs.kde.org/show_bug.cgi?id=409122 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #1 from Martin Steigerwald --- Hi Tom. Thanks for your report. How is that report different from your other report Bug 390733 - KMail cannot send mails using gmail smtp ? -- You are receiving this mail because: You are on the CC list for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 --- Comment #21 from Martin Steigerwald --- Dan, thank you very much! I appreciate your work on Akonadi & KDEPIM! -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 --- Comment #18 from Martin Steigerwald --- Created attachment 120932 --> https://bugs.kde.org/attachment.cgi?id=120932=edit akonadiserver.error with english locale, PostgreSQL properly shut down (In reply to Daniel Vrátil from comment #17) > Thanks for the logs, both of you. Indeed it appears that Akonadi mistakenly > thinks, that Postgres is no longer running. > > Do you guys use non-english locale by default? Yes: % locale LANG=de_DE.UTF-8 LANGUAGE=de LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL= > Could you please run the following command both when Postgres IS running and > when it is NOT running, and paste its output here? > > pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data Running: LANG=en /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: server is running (PID: 25164) /usr/lib/postgresql/11/bin/postgres "-D" "/home/martin/.local/share/akonadi/db_data" "-k/tmp/akonadi-martin.wTqoXj" "-h" "" with my locale: % /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: Server läuft (PID: 25164) /usr/lib/postgresql/11/bin/postgres "-D" "/home/martin/.local/share/akonadi/db_data" "-k/tmp/akonadi-martin.wTqoXj" "-h" "" After akonadictl stop: % LANG=en /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: server is running (PID: 25164) /usr/lib/postgresql/11/bin/postgres "-D" "/home/martin/.local/share/akonadi/db_data" "-k/tmp/akonadi-martin.wTqoXj" "-h" "" with my locale same as above. Stopped PostgreSQL process manually: % LANG=en /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: no server running % /usr/lib/postgresql/11/bin/pg_ctl status --pgdata=$HOME/.local/share/akonadi/db_data pg_ctl: kein Server läuft Test with US english locale: % locale LANG=en LANGUAGE=en LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8 % akonadictl --verbose start % akonadictl stop Works. Stops database process just fine. akonadiserver.error attached. Well Daniel, fix would be easy I bet: Just start external commend with English locale if you need to parse strings in the output. Is there no better way than than parsing output? pg_ctl returns 3 as exit code if server is not running (see pg_ctl (1)): status mode checks whether a server is running in the specified data directory. If it is, the server's PID and the command line options that were used to invoke it are displayed. If the server is not running, pg_ctl returns an exit status of 3. If an accessible data directory is not specified, pg_ctl returns an exit status of 4. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 --- Comment #16 from Martin Steigerwald --- Created attachment 120924 --> https://bugs.kde.org/attachment.cgi?id=120924=edit akonadiserver.error log with akonadictl --verbose start on second start reusing existing PostgreSQL processes On second start with some of the PostgreSQL processes still running, this happens: Found pg_ctl: "/usr/lib/postgresql/11/bin/pg_ctl" Found initdb: "/usr/lib/postgresql/11/bin/pg_ctl" Found a postmaster.pid pidfile, checking whether the server is still running... PostgreSQL for Akonadi is already running, trying to connect to it. Database "akonadi" opened using driver "QPSQL" DbInitializer::run() checking table "SchemaVersionTable" checking table "ResourceTable" It reuses the PostgreSQL processes that were left over from the last akonadictl stop: % ps aux | grep postgres martin 25164 0.0 0.1 214568 26444 ?S19:59 0:00 /usr/lib/postgresql/11/bin/postgres -D /home/martin/.local/share/akonadi/db_data -k/tmp/akonadi-martin.wTqoXj -h martin 25166 0.0 0.1 214696 19412 ?Ss 19:59 0:00 postgres: checkpointer martin 25167 0.0 0.0 214700 9152 ?Ss 19:59 0:00 postgres: background writer martin 25168 0.0 0.0 214568 9496 ?Ss 19:59 0:00 postgres: walwriter martin 25169 0.0 0.0 214976 6508 ?Ss 19:59 0:00 postgres: autovacuum launcher martin 25170 0.0 0.0 69616 5108 ?Ss 19:59 0:00 postgres: stats collector martin 25171 0.0 0.0 214968 6484 ?Ss 19:59 0:00 postgres: logical replication launcher martin 25507 1.4 0.9 229764 160720 ? Ss 20:04 0:02 postgres: martin akonadi [local] idle martin 25516 0.0 0.0 218628 14992 ?Ss 20:04 0:00 postgres: martin akonadi [local] idle martin 25517 0.0 0.0 218628 15052 ?Ss 20:04 0:00 postgres: martin akonadi [local] idle martin 25567 0.0 0.0 218492 12980 ?Ss 20:04 0:00 postgres: martin akonadi [local] idle [… about 20-30 more of these …] if you compare this with my last comment, you see that the PIDs are exactly the same. However there are some additional processes running now. When I stop Akonadi again the following processes remain: % ps aux | grep postgres martin 25164 0.0 0.1 214568 26444 ?S19:59 0:00 /usr/lib/postgresql/11/bin/postgres -D /home/martin/.local/share/akonadi/db_data -k/tmp/akonadi-martin.wTqoXj -h martin 25166 0.0 0.1 214696 19412 ?Ss 19:59 0:00 postgres: checkpointer martin 25167 0.0 0.0 214700 9152 ?Ss 19:59 0:00 postgres: background writer martin 25168 0.0 0.0 214568 9496 ?Ss 19:59 0:00 postgres: walwriter martin 25169 0.0 0.0 214976 6508 ?Ss 19:59 0:00 postgres: autovacuum launcher martin 25170 0.0 0.0 69616 5108 ?Ss 19:59 0:00 postgres: stats collector martin 25171 0.0 0.0 214968 6484 ?Ss 19:59 0:00 postgres: logical replication launcher martin 25781 0.0 0.0 8236 924 pts/3S+ 20:10 0:00 grep postgres So it appears to me that this could be somewhat an intended feature or option of PostgreSQL: If it does not tear down *all* of the processes it can more quickly be started again. However that is still all just guess work until I take the time to dig deeper in how PostgreSQL handles stopping the database. I'd somehow still expect that it would remove all processes. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 --- Comment #15 from Martin Steigerwald --- Created attachment 120923 --> https://bugs.kde.org/attachment.cgi?id=120923=edit akonadiserver.error log with akonadictl --verbose start With KDEPIM/Akonadi 18.08 (I know, still outdated, Debian in deep freeze till likely beginning of July) I can confirm Axel's results. Logfile attached. Some database processes are still running. % ps aux | grep postgres martin 25164 0.0 0.1 214568 26444 ?S19:59 0:00 /usr/lib/postgresql/11/bin/postgres -D /home/martin/.local/share/akonadi/db_data -k/tmp/akonadi-martin.wTqoXj -h martin 25166 0.0 0.0 214568 3928 ?Ss 19:59 0:00 postgres: checkpointer martin 25167 0.0 0.0 214568 5600 ?Ss 19:59 0:00 postgres: background writer martin 25168 0.0 0.0 214568 9496 ?Ss 19:59 0:00 postgres: walwriter martin 25169 0.0 0.0 214976 6508 ?Ss 19:59 0:00 postgres: autovacuum launcher martin 25170 0.0 0.0 69616 5108 ?Ss 19:59 0:00 postgres: stats collector martin 25171 0.0 0.0 214968 6484 ?Ss 19:59 0:00 postgres: logical replication launcher martin 25400 0.0 0.0 8236 928 pts/3S+ 20:01 0:00 grep postgres However if I do not stop the database processes manually it reuses the existing PostgreSQL processes as I show in my next attachment. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 407169] IMAP constantly syncing
https://bugs.kde.org/show_bug.cgi?id=407169 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #1 from Martin Steigerwald --- Dear Aaron, thank you for your report. I saw this as well with Office 365 IMAP. However, I found the default interval is 5 minutes, see settings of IMAP resource. If you have a lot of folders that may explain the regular syncing activity. I set it to 30 minutes meanwhile and it has been better since then. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406856] Found 3734 items without RID.; Item "30024" has RID and is dirty.
https://bugs.kde.org/show_bug.cgi?id=406856 --- Comment #4 from Martin Steigerwald --- Nick, which version are you testing on? Do you use KDEPIM 18.12 or later by chance? If so could you please update the version number to the output of 'akonadictl --version'? -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 Martin Steigerwald changed: What|Removed |Added Version|5.6.1 |5.10.3 --- Comment #11 from Martin Steigerwald --- Achim, thanks. Updated version number. So you see mysqld process around even five minutes after "akonadictl stop"? Please report your findings regarding "items without RID" on: Bug 406856 Found 3734 items without RID.; Item "30024" has RID and is dirty. (Please always put new information on the relevant bug report, to help to keep each bug report concise and to one topic.) I update version number there as well then. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 --- Comment #8 from Martin Steigerwald --- Thank you Axel for confirming on recent version. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406958] Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 --- Comment #4 from Martin Steigerwald --- Christophe, come on now: 5.9.2 is also available. Okay, I bring this up on kdepim-devel mailing list. 18.08 is not even a year old. You are basically telling Linux distro users to get lost by closing bugs from not even one year old versions like this. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 --- Comment #6 from Martin Steigerwald --- Thing is: yes, I understand that it would be tedious to receive bug reports of long fixed bugs with versions that are 2 or more years old. But 18.08 is not even a year. If you are implying that you are not interested in bug reports regarding versions that are not even a year old, you are basically telling Linux distro users to get lost. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 --- Comment #5 from Martin Steigerwald --- 18.08 unmaintained already? Well, FWIW Dan asked me whether Akonadi crashes which may prevent a proper database shutdown¹. Now I did and even used an existing bug report and you just closed it. That basically means that as long as I choose to use the Debian Sid aka Unstable release (not even the one in current Debian Stretch aka Stable) and report any bugs about it, my bugs would be outdated to begin with. My short comment on this: I disagree. [1] https://mail.kde.org/pipermail/kdepim-users/2019-April/001827.html -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 --- Comment #5 from Martin Steigerwald --- Thanks, Wolfgang, for letting us know. I hope after release of Debian Buster I can get updated KDEPIM packages for Debian again. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 386173] akonadictl stop does not shut down database
https://bugs.kde.org/show_bug.cgi?id=386173 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #3 from Martin Steigerwald --- I can confirm this (on a ThinkPad T520 as well:): Akonadi 5.9.3 (from Akonadi/KDEPIM 18.08), no selectable in bugtracker. SUMMARY 'akonadictl stop' does not quit PostgreSQL server. STEPS TO REPRODUCE 1. 'akonadictl stop' while Akonadi and PostgreSQL are running OBSERVED RESULT % akonadictl start Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) % Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) % akonadictl stop % QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open Error writing to file... [… don't know what this is about …] QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open QIODevice::read (QLocalSocket): device not open org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_birthdays_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_indexing_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_contacts_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_notes_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_newmailnotifier_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_mbox_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_followupreminder_agent' exited normally... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_kalarm_resource' exited normally... org.kde.pim.akonadicontrol: Application
[Akonadi] [Bug 389607] akonadictl fsck: Show more helpful messages
https://bugs.kde.org/show_bug.cgi?id=389607 --- Comment #7 from Martin Steigerwald --- Just to confirm that this still happens with Akonadi 5.9.3 (KDEPIM/Akonadi 18.08). Here are some examples of an akonadictl fsck run after switching to PostgreSQL database backend just a few weeks ago: Looking for resources in the DB not matching a configured resource... Looking for collections not belonging to a valid resource... Checking collection tree consistency... Looking for items not belonging to a valid collection... Looking for item parts not belonging to a valid item... Looking for item flags not belonging to a valid item... Looking for overlapping external parts... Verifying external parts... Found 8951 external files. Found 2069 external parts. Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/27/231727_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/37/85637_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/69/230869_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/44/216944_r1 [… >6000 more of those …] Moved 6882 unreferenced files to lost+found. Checking size treshold changes... Found 0 parts to be moved to external files Found 0 parts to be moved to database Looking for dirty objects... Collection "Search" (id: 1) has no RID. Collection "OpenInvitations" (id: 360) has no RID. Collection "DeclinedInvitations" (id: 361) has no RID. Found 3 collections without RID. Item "1144154" in collection "266" has no RID. Item "1144155" in collection "256" has no RID. Item "1144156" in collection "256" has no RID. Item "1144157" in collection "256" has no RID. Item "1144158" in collection "256" has no RID. Item "1144159" in collection "256" has no RID. Item "1144160" in collection "152" has no RID. Item "1144161" in collection "180" has no RID. Item "1144163" in collection "266" has no RID. Item "1144164" in collection "256" has no RID. Item "1144165" in collection "256" has no RID. [… more of those …] Found 43 items without RID. Found 0 dirty items. Looking for rid-duplicates not matching the content mime-type of the parent collection Checking Search Checking Notizen […] Related bugs: - Bug 406958 - Unreferenced files in file_db_data - Bug 406087 - akonadictl fsck incorrectly reports success when file_lost+found folder is absent - Bug 406856 - Found 3734 items without RID.; Item "30024" has RID and is dirty. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 --- Comment #3 from Martin Steigerwald --- Sorry 5.9.3 is KDEPIM/Akonadi 18.08. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406958] Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 --- Comment #2 from Martin Steigerwald --- Sorry 5.9.3 is KDEPIM/Akonadi 18.08. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406958] Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 Martin Steigerwald changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Martin Steigerwald --- Setting to confirmed as Bug 406087 - akonadictl fsck incorrectly reports success when file_lost+found folder is absent which is about akonadi fsck not cleaning up those files, shows that this happened to at least another user with Akonadi 5.9.3. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 --- Comment #2 from Martin Steigerwald --- I also reported a bug about those unreferenced files to begin with: Bug 406958 Unreferenced files in file_db_data -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406958] New: Unreferenced files in file_db_data
https://bugs.kde.org/show_bug.cgi?id=406958 Bug ID: 406958 Summary: Unreferenced files in file_db_data Product: Akonadi Version: 5.9.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Maildir Resource Assignee: kdepim-bugs@kde.org Reporter: mar...@lichtvoll.de Target Milestone: --- I use Akonadi version 5.9.3 (18.04), not selectable in bug tracker under "Version" SUMMARY I switched to PostgreSQL recently, with a completely clear ~/.local/share/akonadi (well except "db_data" directory switch I created before starting Akonadi for the first time after changing database backend). Just a few weeks later I have: Found 8951 external files. Found 2069 external parts. Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/27/231727_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/37/85637_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/69/230869_r1 [… >6000 of those lines ] Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/76/229676_r1 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/15/85215_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/75/172275_r2 Found unreferenced external file: /home/martin/.local/share/akonadi/file_db_data/36/232836_r1 Moved 6882 unreferenced files to lost+found. This is with Maildir filed by POP3 resources. STEPS TO REPRODUCE I have no idea. Probably just use Akonadi for a while. Maybe related to this is: Out of frustration with Akonadi not responding to KMail requests while doing some background processing I did 'akonadictl stop' and after a minute or so as there was still a PostgreSQL process around… friendly stopped it with a SIGTERM. This may have contributed to the situation. OBSERVED RESULT Unreferenced external files. EXPECTED RESULT No unreferences external files during normal operation. I thought one of the main causes for those have been fixed, but it is still or again happening. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.9.3 (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION Bug #282160 is related, but kind of outdated, still referencing Baloo. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406087] akonadictl fsck incorrectly reports success when file_lost+found folder is absent
https://bugs.kde.org/show_bug.cgi?id=406087 Martin Steigerwald changed: What|Removed |Added Ever confirmed|0 |1 CC||mar...@lichtvoll.de Status|REPORTED|CONFIRMED --- Comment #1 from Martin Steigerwald --- Thank you for your report, Brendon. I can confirm this with PostgreSQL as database backend. Using same Akonadi version 5.9.3 (KDEPIM/Akonadi 18.04) on Debian Sid. akonadictl fsck does not move any files to lost+found, it does not even create the directory. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 406856] Found 3734 items without RID.; Item "30024" has RID and is dirty.
https://bugs.kde.org/show_bug.cgi?id=406856 Martin Steigerwald changed: What|Removed |Added Ever confirmed|0 |1 CC||mar...@lichtvoll.de Status|REPORTED|CONFIRMED --- Comment #2 from Martin Steigerwald --- Nick, thank you for your report. I can confirm that this is happening. You may clear up the fsck messages about "item has no RID" with the queries you stated, however… as far as I understand Akonadi assigns a RID once it stored the item in remote storage. For IMAP this would be the IMAP account and for Maildir resource it would be the Maildir. And right now Akonadi's change recorder has no means to retry this failed operation. So items may never end up in the remote storage! Additionally for Maildir I do not get how this operation to store into (the quite local) remote storage could ever fail, as long as the filesystem has enough space. So it could be that those items without RID have not yet been stored to the remote storage and that by deleting them from the database (and if payload stored externally from 'file_db_data') you loose those items (mails, events, contacts, …). So there is a real potential for data loss there. However it also could be that Akonadi just messes up big time like in storing the items into remote storage, but somehow failing to store the remote ID or whatever. I just recently switched from MariaDB to PostgreSQL and already got "Found 43 items without RID." as well as "Moved 6882 unreferenced files to lost+found." (will do a separate bug report about that, since it actually did not even move those files), after just a few weeks of usage. This is with POP3 filling maildir. One thing: On delays during background jobs I sometimes just did "akonadictl stop" and then as PostgreSQL is not stopped completely on my system (yet another bug report), also stop the PostgreSQL process, so this may contribute to the situation. Did you do something similar at times? -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #14 from Martin Steigerwald --- Dan, I just like to remind kindly. This regular crash together with a host of other issues add up and make the KDEPIM experience with KDEPIM/Akonadi 18.08 quite a bit less enjoyable than with previous versions. I do not have access to KDEPIM/Akonadi 18.12 as regular Debian packages yet and this likely will remain so until Debian 10 is released (Freeze). As far as it affects other users it would be important to get a fix into Debian 10. And yes, I know you do this in your spare time. But if you do not have time to look into the backtraces, would you please clearly say so, so I could try to find someone else to look into it? I likely will be mostly or completely offline from Friday to Monday, but after that I'd be able to answer any questions you may have. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #13 from Martin Steigerwald --- Thanks, Christian. Dan, could you have the look at the valgrind traces I produced? The third one would be the most accurate one, I believe. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #11 from Martin Steigerwald --- Created attachment 118575 --> https://bugs.kde.org/attachment.cgi?id=118575=edit third valgrind run, with all dbgsym package and crash Another valgrind run. Hopefully this one is enough to find the issue. This time I have all debug symbols installed. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #10 from Martin Steigerwald --- Created attachment 118539 --> https://bugs.kde.org/attachment.cgi?id=118539=edit second valgrind run, with error-limit=no Second valgrind run: valgrind --error-limit=no --track-origins=yes --num-callers=50 kmail &> 404052-kmail-valgrind.log KMail actually crashed. It did not in the first run. I also installed some additional debug packages, but I still missed some, as I was not aware of "find-dbgsym-packages" from Debian package "debian-goodies". I am uploading in the hope that it may still be enough to pin-point the issue. I may have a go with all debug packages installed later this week, but for now I have enough of a KMail that is so slow it that I can see each rendering operation in slow motion. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #9 from Martin Steigerwald --- I have KMail running under valgrind now. Did not like to crash so far, tough. Once it crashes, it is safe to send the valgrind log to the bugtracker regarding privacy? It currently is 2,1 MiB and it did not grow recently anymore. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 405005] Disappearing menu (edited)
https://bugs.kde.org/show_bug.cgi?id=405005 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #4 from Martin Steigerwald --- Dear Patrick, please use Ctrl-M to get back the menu. I also recommend you to use a more friendly tone in case you like help¹. [1] https://kde.org/code-of-conduct/ -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 393421] No ability to hide the HTML Message Status Bar
https://bugs.kde.org/show_bug.cgi?id=393421 --- Comment #59 from Martin Steigerwald --- (In reply to Peter Humphrey from comment #58) > (In reply to Christoph Feck from comment #55) > > It is a security reason. You could receive an HTML mail that looks like a > > plain text mail, and with HTML you have the ability to embed malicious links > > everywhere. If you have no way to see that the message is actually an HTML > > message, i.e. _outside_ the message viewer, you could click those links > > without being aware that they link to sites that you don't see in the text. > This is completely spurious. If you click on a link, you know it's a link. > If it's a link it must be in HTML. You don't need an ugly great splodge to > tell you it's HTML. > > If you think there are people who can't see this, let them keep the warning. > The rest of us, who've used the Internet for more than five minutes, should > be allowed to switch the splodge off, as we always used to be. Peter, KMail has clickable links also in plain text view. In HTML however the link can go to an entirely different location than what the user gets to see, while in plain text it cannot. Thus there is a valid security concern. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 393421] No ability to hide the HTML Message Status Bar
https://bugs.kde.org/show_bug.cgi?id=393421 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #57 from Martin Steigerwald --- Nate, I agree that the current solution looks quite out of place. There is the writing "no HTML message" black on white when the message just has no HTML part. There is the writing "clear text message" black on white, when it has one but the cleartext part is shown. There is the writing "HTML message" white on black when the HTML part is shown. And then there is a bug when switching from HTML part back to clear text part, it still display "HTML message" white on black. So first the choice of colors IMHO is just ugly. The colors do not blend well with Breeze Dark theme. The white on black "HTML message" bar totally looks out of place. Second it has three states, while for the user only one information is important: Is what is currently viewed HTML or is it not. With the option that when both clear text and HTML are available, that HTML status bar allows to toggle. In addition in my KMail configuration for security reason I do not even let it render HTML without my prior confirmation. Thus I have a box with red frame at the top of the mail with "Note: This is an HTML message. For security reasons, only the raw HTML code is shown. […]" giving me the option to enable HTML rendering in case I trust the sender. In case KMail is configured like this the vertical bar is completely superfluous. I believe with good user interface design it might be possible to merge both this box and the HTML status bar into one and make it less intrusive. Laurent, Christoph, I kindly ask you to reconsider and at ask for input from VDG team. And if on it, it might be good when VDG people look through the rest of the application as well. Thus I'd reopen the bug and set usability tag. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 390798] Akonadi EWS failed to authenticate with Exchange Server
https://bugs.kde.org/show_bug.cgi?id=390798 Martin Steigerwald changed: What|Removed |Added Resolution|REMIND |--- Status|NEEDSINFO |CONFIRMED --- Comment #19 from Martin Steigerwald --- Olivier, thank you for confirming with newest version. What version does your Exchange server have? Can anyone else confirm it? I am a bit puzzled about the bug report after reading through it again. I have the feeling that it is about several different issues. So or so would be helpful to have some logging / console output, when the issue happens. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #7 from Martin Steigerwald --- Is this backtrace – after installing libkf5akonadicore5abi2-dbgsym and libkf5coreaddons5-dbgsym – more useful? I may come around to the valgrind thing, if still required, next week: 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 0x7f24e04daf00 (LWP 26945))] Thread 30 (Thread 0x7f23b1fb3700 (LWP 6366)): #0 0x7f24f67b73a9 in futex_reltimed_wait_cancelable (private=0, reltime=0x7f23b1fb2400, expected=0, futex_word=0x7f23b1fb25e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f24f67b73a9 in __pthread_cond_wait_common (abstime=0x7f23b1fb24a0, mutex=0x7f23b1fb2598, cond=0x7f23b1fb25c0) at pthread_cond_wait.c:533 #2 0x7f24f67b73a9 in __pthread_cond_timedwait (cond=0x7f23b1fb25c0, mutex=0x7f23b1fb2598, abstime=0x7f23b1fb24a0) at pthread_cond_wait.c:667 #3 0x7f24efe03a37 in base::ConditionVariable::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #4 0x7f24efe0630a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #5 0x7f24efe063f2 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #6 0x7f24efe0a981 in base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f24efe0bc7f in base::internal::SchedulerWorker::Thread::ThreadMain() () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #8 0x7f24efe14c81 in base::(anonymous namespace)::ThreadFunc(void*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #9 0x7f24f67b0fa3 in start_thread (arg=) at pthread_create.c:486 #10 0x7f24f8f7780f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 29 (Thread 0x7f23b3ff5700 (LWP 6039)): #0 0x7f24f67b73a9 in futex_reltimed_wait_cancelable (private=0, reltime=0x7f23b3ff4400, expected=0, futex_word=0x7f23b3ff45e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f24f67b73a9 in __pthread_cond_wait_common (abstime=0x7f23b3ff44a0, mutex=0x7f23b3ff4598, cond=0x7f23b3ff45c0) at pthread_cond_wait.c:533 #2 0x7f24f67b73a9 in __pthread_cond_timedwait (cond=0x7f23b3ff45c0, mutex=0x7f23b3ff4598, abstime=0x7f23b3ff44a0) at pthread_cond_wait.c:667 #3 0x7f24efe03a37 in base::ConditionVariable::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #4 0x7f24efe0630a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #5 0x7f24efe063f2 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #6 0x7f24efe0a981 in base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f24efe0be61 in base::internal::SchedulerWorker::Thread::ThreadMain() () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #8 0x7f24efe14c81 in base::(anonymous namespace)::ThreadFunc(void*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #9 0x7f24f67b0fa3 in start_thread (arg=) at pthread_create.c:486 #10 0x7f24f8f7780f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 28 (Thread 0x7f23b57f8700 (LWP 5272)): #0 0x7f24f67b73a9 in futex_reltimed_wait_cancelable (private=0, reltime=0x7f23b57f7400, expected=0, futex_word=0x7f23b57f75e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f24f67b73a9 in __pthread_cond_wait_common (abstime=0x7f23b57f74a0, mutex=0x7f23b57f7598, cond=0x7f23b57f75c0) at pthread_cond_wait.c:533 #2 0x7f24f67b73a9 in __pthread_cond_timedwait (cond=0x7f23b57f75c0, mutex=0x7f23b57f7598, abstime=0x7f23b57f74a0) at pthread_cond_wait.c:667 #3 0x7f24efe03a37 in base::ConditionVariable::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #4 0x7f24efe0630a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #5 0x7f24efe063f2 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #6 0x7f24efe0a981 in base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f24efe0be61 in base::internal::SchedulerWorker::Thread::ThreadMain() () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #8 0x7f24efe14c81 in base::(anonymous namespace)::ThreadFunc(void*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #9 0x7f24f67b0fa3 in start_thread (arg=) at pthrea
[Akonadi] [Bug 403903] does not respect org.kde.pim.ews.client: a:ErrorServerBusy: The server cannot service this request right now. Try again later.
https://bugs.kde.org/show_bug.cgi?id=403903 --- Comment #14 from Martin Steigerwald --- Aaron, thank you for the updates. I totally understand your situation and frustration. I did not opt in for Office 365 either. I currently use Evolution with EWS, which appears to work – will have another go with Akonadi EWS next week (but with 18.08.3). However, please let us keep this bug report to the actual issue at hand and discuss possible alternatives and so on kdepim-users. Let's try to keep the bug report concise, so it is easy for Kriss to act on it, once he managed to take the time for it. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 402780] Akonadi doesn't work with Exchange again
https://bugs.kde.org/show_bug.cgi?id=402780 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de --- Comment #5 from Martin Steigerwald --- Dear Tom, while I certainly get your frustration and also share it to quite some extent, I actually know that KDEPIM developers care *a lot* about KDEPIM. But there are only a few of them regularly working on KDEPIM. About the developer of EWS resource I know that he started developing it as his employer migrated to Office 365. That means: The developer has a day job. The money is coming from that day job. Your bug report is about one month old. That is not all that old for a component of Akonadi that someone develops in his spare time. It is a free software project, so in case you like to change the situation you are free to help. So please keep it constructive here and vent your frustration on a different place (like the kdepim-users mailing list if you must, but even there, I suggest you avoid blaming others). This is a bug tracker, no discussion forum. The longer a bug report gets, the less likely it is for someone to be able to dig out the relevant information quickly. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 403903] does not respect org.kde.pim.ews.client: a:ErrorServerBusy: The server cannot service this request right now. Try again later.
https://bugs.kde.org/show_bug.cgi?id=403903 --- Comment #11 from Martin Steigerwald --- Thanks a lot for the detailed traces. Let's hope Kriss can have a look at it. (I am in the same position as my employer decided to migrate to Office 365. Privately I will keep Dovecot.) -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 404079] EWS will not download new email anymore after a:ErrorServerBusy: The server cannot service this request right now. Try again later.
https://bugs.kde.org/show_bug.cgi?id=404079 Martin Steigerwald changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #4 from Martin Steigerwald --- Aaron, you provided a trace when Akonadi EWS gets eServerBusy and it never recovers and seems to be stuck in the other bug report: does not respect org.kde.pim.ews.client: a:ErrorServerBusy: The server cannot service this request right now. Try again later. https://bugs.kde.org/show_bug.cgi?id=403903#c4 Thus setting this to REPORTED again. Let's hope Kriss kann have a look at it. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 403903] does not respect org.kde.pim.ews.client: a:ErrorServerBusy: The server cannot service this request right now. Try again later.
https://bugs.kde.org/show_bug.cgi?id=403903 --- Comment #2 from Martin Steigerwald --- Bug 404079 - EWS will not download new email anymore after a:ErrorServerBusy: The server cannot service this request right now. Try again later. is related. Apparently Akonadi EWS can get completely stuck after not respecting a:ErrorServerBusy. (BTW for me it is complete news to me that a mail or groupware server can report that it is busy. My private Dovecot IMAP/POP3 *never* *ever* did that. And it points out that there is an issue Microsoft might be responsible for – unless Akonadi EWS is doing something excessive here. However, also if the error means that Microsoft failed to allocate sufficient resources for the service, it still would be good that Akonadi EWS respects it. :) -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 404079] EWS will not download new email anymore after a:ErrorServerBusy: The server cannot service this request right now. Try again later.
https://bugs.kde.org/show_bug.cgi?id=404079 Martin Steigerwald changed: What|Removed |Added Summary|EWS will not download new |EWS will not download new |email |email anymore after ||a:ErrorServerBusy: The ||server cannot service this ||request right now. Try ||again later. Severity|grave |major --- Comment #3 from Martin Steigerwald --- Okay, Aaron, thanks for your prompt update. Lowering severity as there is no data loss involved. (Severity is not how you feel about the bug, but about how severe it factually is.) I found that you already reported something similar: Bug 403903 - org.kde.pim.ews.client: a:ErrorServerBusy: The server cannot service this request right now. Try again later. I am trying to see how this bug report is not a duplicate of your older bug report: So what is new here is that you like to point out that Akonadi EWS, after not respecting ErrorServerBusy, gets stuck completely? For now I have changed the title as such. Feel free to clarify and change the title as you see fit. Do you see anything in the logs that is different from what you mentioned in bug 403903? -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 403903] does not respect org.kde.pim.ews.client: a:ErrorServerBusy: The server cannot service this request right now. Try again later.
https://bugs.kde.org/show_bug.cgi?id=403903 Martin Steigerwald changed: What|Removed |Added CC||mar...@lichtvoll.de Summary|org.kde.pim.ews.client: |does not respect |a:ErrorServerBusy: The |org.kde.pim.ews.client: |server cannot service this |a:ErrorServerBusy: The |request right now. Try |server cannot service this |again later.|request right now. Try ||again later. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 404079] EWS will not download new email
https://bugs.kde.org/show_bug.cgi?id=404079 Martin Steigerwald changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||mar...@lichtvoll.de Status|REPORTED|NEEDSINFO --- Comment #1 from Martin Steigerwald --- Dear Aaron. As frustrating that experience sounds, are you actually *sure* that those mails are lost? If they are still accessible within Outlook Web Access, they are not lost. Remember – except for some state information, configuration and delayed updating of remote resources – Akonadi is just a cache. Akonadi misconception #1: where is my data? https://blogs.kde.org/2011/11/13/akonadi-misconception-1-where-my-data Please check whether the mails you miss are still accessible within Outlook Web Access (or another mail client using OWA like Evolution with evolution-ews) and report back. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 390260] akonadi-ews-resource segfault
https://bugs.kde.org/show_bug.cgi?id=390260 Martin Steigerwald changed: What|Removed |Added Resolution|REMIND |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #4 from Martin Steigerwald --- Hello Kai. Thank you for the information. I am closing this bug cause as you do not use KDEPIM/Akonadi anymore, you would not provide any further information – for example whether this segfault still exists. If anyone finds this segfault again, please open a new bug. Thank you. As for Baloo: That is a different topic, but this bug tracker is not the place to discuss it. However, in case you can confirm [frameworks-baloo] [Bug 404057] New: Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing please comment there, so I can set it to CONFIRMED. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #4 from Martin Steigerwald --- Okay, on one hand DrKonqi does not thing the backtraces are related, on the other hand it truncates the backtrace when I tell it to add it to the bug report. Since I do not know whether DrKonqi got this right, this time I add the full backtrace manually: 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 0x7f0102391f00 (LWP 13263))] Thread 30 (Thread 0x7f00d8a49700 (LWP 14328)): #0 0x7f011866e3a9 in futex_reltimed_wait_cancelable (private=0, reltime=0x7f00d8a48400, expected=0, futex_word=0x7f00d8a485e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f011866e3a9 in __pthread_cond_wait_common (abstime=0x7f00d8a484a0, mutex=0x7f00d8a48598, cond=0x7f00d8a485c0) at pthread_cond_wait.c:533 #2 0x7f011866e3a9 in __pthread_cond_timedwait (cond=0x7f00d8a485c0, mutex=0x7f00d8a48598, abstime=0x7f00d8a484a0) at pthread_cond_wait.c:667 #3 0x7f0111cbaa37 in base::ConditionVariable::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #4 0x7f0111cbd30a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #5 0x7f0111cbd3f2 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #6 0x7f0111cc1981 in base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f0111cc2e61 in base::internal::SchedulerWorker::Thread::ThreadMain() () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #8 0x7f0111ccbc81 in base::(anonymous namespace)::ThreadFunc(void*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #9 0x7f0118667fa3 in start_thread (arg=) at pthread_create.c:486 #10 0x7f011ae2e80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 29 (Thread 0x7effdb1d7700 (LWP 14274)): #0 0x7f011ae3ba8b in __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63 #1 0x7f011ae3d814 in ___fprintf_chk (fp=0x7f011aef28b0 <_IO_stdfile_2_lock>, flag=1, format=0x7f010cc59848 "[%s] %s\n") at fprintf_chk.c:30 #2 0x7f010cc41a5a in event_logv_ () at /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6 #3 0x7f010cc41c34 in event_warn () at /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6 #4 0x7f010cc43588 in () at /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6 #5 0x7f010cc39329 in event_base_loop () at /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6 #6 0x7f0111c8f7cd in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f0111caec8b in base::RunLoop::Run() () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #8 0x7f0111cd0204 in base::Thread::ThreadMain() () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #9 0x7f0111ccbc81 in base::(anonymous namespace)::ThreadFunc(void*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #10 0x7f0118667fa3 in start_thread (arg=) at pthread_create.c:486 #11 0x7f011ae2e80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 28 (Thread 0x7f00caffd700 (LWP 14088)): #0 0x7f011866e3a9 in futex_reltimed_wait_cancelable (private=0, reltime=0x7f00caffc400, expected=0, futex_word=0x7f00caffc5e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f011866e3a9 in __pthread_cond_wait_common (abstime=0x7f00caffc4a0, mutex=0x7f00caffc598, cond=0x7f00caffc5c0) at pthread_cond_wait.c:533 #2 0x7f011866e3a9 in __pthread_cond_timedwait (cond=0x7f00caffc5c0, mutex=0x7f00caffc598, abstime=0x7f00caffc4a0) at pthread_cond_wait.c:667 #3 0x7f0111cbaa37 in base::ConditionVariable::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #4 0x7f0111cbd30a in base::WaitableEvent::TimedWaitUntil(base::TimeTicks const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #5 0x7f0111cbd3f2 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #6 0x7f0111cc1981 in base::internal::SchedulerWorker::Delegate::WaitForWork(base::WaitableEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #7 0x7f0111cc2e61 in base::internal::SchedulerWorker::Thread::ThreadMain() () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #8 0x7f0111ccbc81 in base::(anonymous namespace)::ThreadFunc(void*) () at /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 #9 0x7f0118667fa3 in start_thread (arg=) at pthread_create.c:486 #10 0x7f011ae2e80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 27 (Thread 0x7f005bfff700 (LWP 13527)): #0 0x7f011866df
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #3 from Martin Steigerwald --- Created attachment 117912 --> https://bugs.kde.org/attachment.cgi?id=117912=edit New crash information added by DrKonqi kmail (5.9.3) using Qt 5.11.3 - What I was doing when the application crashed: Another backtrace. Let's see whether DrKonqi truncates this one as well. If it does, I will cut and paste the full backtrace in a moment. -- Backtrace (Reduced): #6 0x7f011959515a in () at /usr/lib/x86_64-linux-gnu/libKF5AkonadiCore.so.5abi2 #7 0x7f01195db2ef in Akonadi::Item::hasAttribute(QByteArray const&) const () at /usr/lib/x86_64-linux-gnu/libKF5AkonadiCore.so.5abi2 #8 0x7f01196c5a7e in () at /usr/lib/x86_64-linux-gnu/libKF5AkonadiCore.so.5abi2 #9 0x7f01196c3154 in () at /usr/lib/x86_64-linux-gnu/libKF5AkonadiCore.so.5abi2 #10 0x7f01196b342a in () at /usr/lib/x86_64-linux-gnu/libKF5AkonadiCore.so.5abi2 -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash during/after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 Martin Steigerwald changed: What|Removed |Added Summary|Crash after filtering |Crash during/after |inbox, probably related to |filtering inbox, probably |Qt WebEngine integration|related to Qt WebEngine ||integration -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 404052] Crash after filtering inbox, probably related to Qt WebEngine integration
https://bugs.kde.org/show_bug.cgi?id=404052 --- Comment #2 from Martin Steigerwald --- I do not know why DrKonqi reduced the backtrace. It definately looked longer. -- You are receiving this mail because: You are the assignee for the bug.
