[kimap] [Bug 352883] remote changes to message read/important state on gmail imap account aren't synced
https://bugs.kde.org/show_bug.cgi?id=352883 RJVB changed: What|Removed |Added Resolution|--- |UNMAINTAINED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #45 from RJVB --- (In reply to Wolfgang Bauer from comment #44) > I do use QtWebKit with konqueror, and opening large OBS logs (which are just > text files) do take a while. TBH, Konqueror is such a multipurpose tool that I have no idea what backend/engine/kpart it uses for rendering pure text. Actually, when I open /var/log/syslog I get a view that suggest very strongly that the Kate text editor kpart is used. That is, if I open the file from within Konqueror. If I try to start konqueror with a file it will start but open the file in the system handler (Kate for text files), very funny. > That's what I meant with a "large rewrite" amongst other things. > Please note that I'm not a kmail developer though. Neither am I, and you're right in assuming it could be more work than you'd expect. > I'm not sure though, nor if it frees the resources when you switch to a > different mail (I think it does). In my experience that doesn't always mean the resources are available immediately, for RAM at least. But I digress... -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #43 from RJVB --- (In reply to Wolfgang Bauer from comment #42) > Have you tried in Chromium though? (which is what QtWebEngine is based upon) Current versions of Firefox tend to consume more memory than Chromium - in fact,I understand that the Firefox Quantum engine uses bits and pieces from all 3 open source web engines and picks the fastest one. > TBH, I think even QtWebKit would struggle with these large mails That would be simple to test in konqueror with the webkit backend, or Otter-Browser, and the rebooted QtWebKit. Or in epiphany. 1 caveat emptor: we don't actually know what clever tricks the web email interface pulls. > Anyway, this is kind of a different problem than comment#35 (or comment#0). > I don't see how it could be fixed from the kmail side, except for not trying > to display mails larger than a certain size at all. (or maybe just display > it as plain text instead then, but that probably means a large rewrite of > the code, and I'm not sure it's possible at all) - Don't dump the entire message into the rendering widget but use a paged approach - wrapper code can be written that connects to different backends. If you don't want to support QtWebkit, fine, but there's also QTextBrowser which should be sufficient even for simple HTML emails (it's what Qt's assistant uses by default since whatever Qt version that obsoleted QtWebkit). I've done a compile-time version of such wrapper code for KDevelop's help browser (which supports both QWE and QWK). I think it should be possible at least to chose between backends as a startup option. Out of curiosity: does that humongous QWE process exit when you close the message view, or do you have to quit KMail to recuperate all that RAM? -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #39 from RJVB --- A pure text email of 35Mb is massive too, but eating around 4Gb of RAM for that isn't just massive. That's what you meant, right, not 4Mb for displaying just the part that fits in your window (which would seem reasonable)? 4Gb, that's about 120 times the size of the email. I knew KMail would become a powerkids' tool with the design decision to use a full-fledged-browser-in-a-widget (QtWebEngine) for rendering everything including pure text emails but I wasn't expecting this. Then again, I don't usually get this kind of long letters by email so I have no idea how any other MUA would handle them. If the account you got this email on has a web/browser interface it would be interesting to estimate the resources an actual browser (GChrome or Chromium) would use to display it, for comparison. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 411486] New: [feature request]: select none
https://bugs.kde.org/show_bug.cgi?id=411486
Bug ID: 411486
Summary: [feature request]: select none
Product: kmail2
Version: unspecified
Platform: Compiled Sources
OS: All
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: folders
Assignee: kdepim-bugs@kde.org
Reporter: rjvber...@gmail.com
Target Milestone: ---
I hope this is still the place to lodge feature requests?
I have had one for a long time: an option not to select anything upon entering
a new mail folder, or after certain operations like deleting the currently
selected message(s). The former was relatively straightforward to implement in
KMail 4.1x days, the latter I never figured out.
I could draft a list of "hard" reasons exactly why I miss this feature, but
underneath they all share the question "why would you *have* to select
anything" in the situations outlined above? An email reader isn't really
different from a file browser ("explorer"), and how many of those do you know
that will always select a file when you move into a new folder, or delete a
file? True, a file system doesn't have the added notion of "new, unread", but
then again a MUA isn't used exclusively to read (and possibly delete/archive)
new mail. ALL new mail.
2 reasons why a forced selection can be annoying:
- you keep having to switch those messages back to "unread" that you want to
keep in that state (and I'm not even talking about messages that have a confirm
read request set).
- you keep having to scroll back the folder message list because that
obligatory selection happens to fall somewhere that shouldn't be visible.
--
You are receiving this mail because:
You are the assignee for the bug.
[kmail2] [Bug 387061] Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #8 from RJVB --- > As I learned now from vkrause, there is a 2MB limit inside QtWEbEngine > (http://doc.qt.io/qt-5/qwebengineview.html#setHtml). So we will have to > rework the part that pushed the content to not use setHtml and use instead a > file. Or go back to using QtWebKit (ReBooted), which is better for just about anything but full-blown browsers anyway? ;) -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 315568] kmail crash on startup
https://bugs.kde.org/show_bug.cgi?id=315568 --- Comment #54 from RJVB --- No, that's not your fault. Qt 4.8.7 was released well before distros started shipping KF5 desktops, and some of the distros covered by my remark are still under LTS. FWIW, most if not all of the Kubuntu 14.04 patches to Qt 4.8.6 still apply to 4.8.7; creating upgraded packages in my own PPA wasn't hard at all. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 315568] kmail crash on startup
https://bugs.kde.org/show_bug.cgi?id=315568 --- Comment #52 from RJVB --- I *think* I stopped seeing this crash after updating to Qt 4.8.7 . Please try that (it's a real shame that distros leave people stranded on such an old version for so long.) -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 339006] message list fonts: use bold/italic/etc as attributes rather than as font instances
https://bugs.kde.org/show_bug.cgi?id=339006 --- Comment #2 from RJVB --- FWIW, the possibly-related problem with SemiBold is due to a font weight handling issue in Qt5 itself. -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 371228] enable remote search on IMAP servers
https://bugs.kde.org/show_bug.cgi?id=371228 --- Comment #1 from RJVB --- Created attachment 101647 --> https://bugs.kde.org/attachment.cgi?id=101647&action=edit a first draft for enabling remote search in the QuickSearch toolbar. WIP! -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 371228] enable remote search on IMAP servers
https://bugs.kde.org/show_bug.cgi?id=371228 RJVB changed: What|Removed |Added CC||d...@newtech.fi -- You are receiving this mail because: You are the assignee for the bug.
[kmail2] [Bug 371228] New: enable remote search on IMAP servers
https://bugs.kde.org/show_bug.cgi?id=371228 Bug ID: 371228 Summary: enable remote search on IMAP servers Product: kmail2 Version: unspecified Platform: Other OS: other Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: message list Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Dan suggested on the kdepim-users ML that someone might want to submit a wishticket for a feature to allow remote search on IMAP servers, all the more since support for the feature is already implemented but dormant. In his words: > maybe we could add a checkbox to the "Quick Search" to enable it and allow > full-text search in a specific folder even if the bodies are not available > locally. Would not work for the "Search" dialog though. I've taken the bait, so here's the wish ticket :) Reproducible: Always Steps to Reproduce: Do a search in an IMAP folder which isn't configured to download all message bodies. Actual Results: Messages not available locally are skipped Expected Results: Those messages could be included on user request I've started to implement the feature. As I'm still using 4.14 that's the code base I'm using, but I suppose that porting should be relatively straightforward. The available support I've been able to find is part of Akonadi::SearchCreateJob, so that's what I've tried to use. Currently I'm getting a "cannot create persistent search" error, and I'm still stuck at how to get the actual results from the returned collection, but I hope it's a start. I'm not entirely sure why remote search couldn't be part of the "Search" dialog, given that the underlying code uses classes that support remote search?? -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 340813] sometimes two copies of mysqld are running with Akonadi
https://bugs.kde.org/show_bug.cgi?id=340813 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #13 from RJVB --- So here's an additional observation, from 4.13.3/ akonadi 1.13.1 but maybe still useful. As I just reported in a duplicate (https://bugs.kde.org/show_bug.cgi?id=367638) I get the 1452 error even when I don't have 2 mysql daemons running. Not continuously at least. Looking at it today I first thought that they were generated only after a full sync (Ctrl-L) but then I noticed the error messages also appeared while I was browsing an email and no sync activity was occurring. I then made the link with the search folder I created yesterday, which was designed to combine the entries from several folders in a virtual folder. For that, I defined a search working on the folders of interest and returning all items with a total size >= 0kb. I left the 2nd field empty. When I deleted that search folder the error messages disappeared, but the unread email in one of the target folders disappeared too. From kmail; Claws shows they're still there, fortunately. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 367638] DATABASE ERROR: 1452
https://bugs.kde.org/show_bug.cgi?id=367638 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #2 from RJVB --- I wouldn't be so sure that this error only occurs when 2 mysql daemons are running. I've been seeing this for ages with 14.3.3 and 14.4 (git/head) with the latest akonadi 1.13.1. For a while now my Linux rig (4.13.3) has been immune to it and only my OS X system gave the errors. They disappeared from (and now reappeared on) the Linux system after some combination of fsck and vacuum, and I think the same may have happened on OS X. just for kicks, this is what I currently see on my akonadi terminal after each complete sync (Ctrl-L). I must assume there's potentially a single folder in my list which is the culprit, but I have a bit too many of them to do manual refreshes one by one to find the trouble folder(s). DATABASE ERROR: Error code: 1452 DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to execute statement" Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)" DATABASE ERROR: Error code: 1452 DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to execute statement" Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)" DATABASE ERROR: Error code: 1452 DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to execute statement" Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)" DATABASE ERROR: Error code: 1452 DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to execute statement" Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)" DATABASE ERROR: Error code: 1452 DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to execute statement" Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)" DATABASE ERROR: Error code: 1452 DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`
[kontact] [Bug 370646] Crash because of stale (dangling) pointers in the attribute registry
https://bugs.kde.org/show_bug.cgi?id=370646 RJVB changed: What|Removed |Added URL||http://arstechnica.com/civi ||s/viewtopic.php?p=32070659# ||p32070659 -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 370646] Crash because of stale (dangling) pointers in the attribute registry
https://bugs.kde.org/show_bug.cgi?id=370646 --- Comment #8 from RJVB --- This bug has gotten under my skin. Having looked at this a bit more and asking around a bit, the most likely explanation for the crash is this: - KCModuleLoader::loadModule() loads the library to get a pointer to the create_ function. The library registers its attributes. - libnoteshared (or the kcm depending on it) doesn't have such a function, and so KCModuleLoader::loadModule() unloads the library again - somewhat thereafter, the library (and/or the kcm depending on it) is loaded once more, and again registers its attributes - the attribute factory finds a previous registration, and attempts to delete the registered attributes - since the library was unloaded and reloaded since those attributes were "new'ed", the dtor lives (potentially) at a different address. - delete *it invokes the dtor ... which may SEGV if the dtor address has changed. I see that `KCModuleLoader::loadModule()` has hardly changed and not at all in the aspects outlined above. IOW, this bug is likely to occur in KDE PIM5 too if libnoteshared hasn't obtained a create_ function since. -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 370646] Crash because of stale (dangling) pointers in the attribute registry
https://bugs.kde.org/show_bug.cgi?id=370646 RJVB changed: What|Removed |Added Summary|Crash when opening Kontact |Crash because of stale |preferences |(dangling) pointers in the ||attribute registry -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 370646] Crash when opening Kontact preferences
https://bugs.kde.org/show_bug.cgi?id=370646
--- Comment #7 from RJVB ---
I see there's been a chronological glitch in my comments :-/
I wonder: shouldn't it be more elegant to do the actual unregistering
(attributes.erase(x)) in the Attribute dtor? I'll need to check if the
Attribute dtor is actually called when libnoteshared is unloaded and that
apparently leads to freeing memory allocated ("new'ed") by that library. If it
is, a lot of the above patches will be handled automatically.
--
You are receiving this mail because:
You are the assignee for the bug.
[kontact] [Bug 370646] Crash when opening Kontact preferences
https://bugs.kde.org/show_bug.cgi?id=370646 --- Comment #6 from RJVB --- #1 (anonymous namespace)::NoteSharedRegistrar::~NoteSharedRegistrar()() at .../kdepim-4.14.git/noteshared/attributes/attributeregistrar.cpp:44 #2 (anonymous namespace)::NoteSharedRegistrar::~NoteSharedRegistrar()() at .../kdepim-4.14.git/noteshared/attributes/attributeregistrar.cpp:43 #3 (anonymous namespace)::$_0::destroy()() at .../kdepim-4.14.git/noteshared/attributes/attributeregistrar.cpp:55 #4 __cxa_finalize() at ??:-1 #5 dyld::garbageCollectImages()() at ??:-1 #6 dlclose() at ??:-1 #7 dlclose() at ??:-1 #8 QLibraryPrivate::unload_sys()() at ??:-1 #9 QLibraryPrivate::unload()() at ??:-1 #10 QPluginLoader::unload()() at ??:-1 #11 KCModuleLoader::loadModule(KCModuleInfo const&, KCModuleLoader::ErrorReporting, QWidget*, QStringList const&)() at ??:-1 #12 KCModuleProxyPrivate::loadModule()() at ??:-1 #13 KCModuleProxy::realModule() const() at ??:-1 #14 KCMultiDialog::addModule(KCModuleInfo const&, KPageWidgetItem*, QStringList const&)() at ??:-1 #15 KSettings::DialogPrivate::createDialogFromServices()() at ??:-1 #16 KSettings::Dialog::showEvent(QShowEvent*)() at ??:-1 #17 QWidget::event(QEvent*)() at ??:-1 #18 QApplicationPrivate::notify_helper(QObject*, QEvent*)() at ??:-1 #19 QApplication::notify(QObject*, QEvent*)() at ??:-1 #20 QCoreApplication::notifyInternal(QObject*, QEvent*)() at ??:-1 -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 370646] Crash when opening Kontact preferences
https://bugs.kde.org/show_bug.cgi?id=370646
--- Comment #5 from RJVB ---
I don't understand how or why dynamically allocated memory can go stale when
the shared library which allocated it is unloaded, but apparently something
like that happens.
When I replace libnoteshared's attributeregistrar's mechanism with one that
create a global class instance when the library is loaded, I can clearly see
that instance being destroyed. I'll have a look at the backtrace leading into
that dtor, but meanwhile, here's a fix. It extends the AttributeFactory with a
method that returns the newly created attribute instance, and (a circuitous)
one that allows to unregister attributes.
The resulting libraries are ABI compatible, and Kontact no longer crashes
Patch for kdepimlibs4:
diff --git akonadi/attributefactory.cpp akonadi/attributefactory.cpp
index 47a8839..51306f0 100644
--- akonadi/attributefactory.cpp
+++ akonadi/attributefactory.cpp
@@ -30,6 +30,7 @@
#include "entityannotationsattribute.h"
#include
+#include
#include
@@ -79,7 +80,18 @@ class StaticAttributeFactory : public AttributeFactory
public:
StaticAttributeFactory()
: AttributeFactory()
-, initialized(false) {}
+, initialized(false)
+, notDeleted(0) {
+skipList << QLatin1String("NoteDisplayAttribute")
+<< QLatin1String("NoteAlarmAttribute")
+<< QLatin1String("KJotsLockAttribute")
+<< QLatin1String("showfoldernotesattribute");
+}
+~StaticAttributeFactory() {
+if (notDeleted > 0) {
+kWarning(5250) << Q_FUNC_INFO << "attributes not deleted:" <<
notDeleted;
+}
+}
void init() {
if (initialized) {
return;
@@ -98,6 +110,8 @@ public:
AttributeFactory::registerAttribute();
}
bool initialized;
+size_t notDeleted;
+QStringList skipList;
};
K_GLOBAL_STATIC(StaticAttributeFactory, s_attributeInstance)
@@ -113,6 +127,9 @@ class AttributeFactory::Private
{
public:
QHash attributes;
+Private() {
+attributes.clear();
+}
};
AttributeFactory *AttributeFactory::self()
@@ -132,18 +149,35 @@ AttributeFactory::~ AttributeFactory()
delete d;
}
+#include
void AttributeFactory::registerAttribute(Attribute *attr)
{
Q_ASSERT(attr);
Q_ASSERT(!attr->type().contains(' ') && !attr->type().contains('\'') &&
!attr->type().contains('"'));
QHash::Iterator it =
d->attributes.find(attr->type());
if (it != d->attributes.end()) {
-delete *it;
+// if
(!s_attributeInstance->skipList.contains(QLatin1String(attr->type( {
+delete *it;
+// } else {
+// s_attributeInstance->notDeleted += 1;
+// }
d->attributes.erase(it);
}
d->attributes.insert(attr->type(), attr);
}
+void AttributeFactory::unRegisterAttribute(Attribute *attr)
+{
+Q_ASSERT(attr);
+Q_ASSERT(!attr->type().contains(' ') && !attr->type().contains('\'') &&
!attr->type().contains('"'));
+kDebug(5250) << Q_FUNC_INFO << "deleting entry for type" << attr->type()
<< attr;
+QHash::Iterator it =
d->attributes.find(attr->type());
+if (it != d->attributes.end()) {
+delete *it;
+d->attributes.erase(it);
+}
+}
+
Attribute *AttributeFactory::createAttribute(const QByteArray &type)
{
Attribute *attr = self()->d->attributes.value(type);
diff --git akonadi/attributefactory.h akonadi/attributefactory.h
index 647b67e..be3b471 100644
--- akonadi/attributefactory.h
+++ akonadi/attributefactory.h
@@ -60,6 +60,16 @@ public:
{
AttributeFactory::self()->registerAttribute(new T);
}
+template inline static T *getRegisteredAttribute()
+{
+T *attr = new T;
+AttributeFactory::self()->registerAttribute(attr);
+return attr;
+}
+inline static void deRegisterAttribute(Attribute *attr)
+{
+AttributeFactory::self()->unRegisterAttribute(attr);
+}
/**
* Creates an entity attribute object of the given type.
@@ -76,6 +86,7 @@ protected:
private:
static AttributeFactory *self();
void registerAttribute(Attribute *attribute);
+void unRegisterAttribute(Attribute *attribute);
class Private;
Private *const d;
Patch for kdepim4:
diff --git noteshared/attributes/attributeregistrar.cpp
noteshared/attributes/attributeregistrar.cpp
index cdcc949..56a61c0 100644
--- noteshared/attributes/attributeregistrar.cpp
+++ noteshared/attributes/attributeregi
[kontact] [Bug 370646] Crash when opening Kontact preferences
https://bugs.kde.org/show_bug.cgi?id=370646 --- Comment #4 from RJVB --- Why this happens is unclear to me, but the line const bool registered = dummy(); in libnoteshared's attributeregistrar.cpp is executed twice. I think that can only happen when the library is loaded twice. I may be saying something stupid here, but if the library gets unloaded without removing its registered attributes, are their addresses still valid when the library is loaded next? -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 370646] Crash when opening Kontact preferences
https://bugs.kde.org/show_bug.cgi?id=370646 --- Comment #3 from RJVB --- I ran kontact through valgrind to get another angle. I think in the end it just confirms what I already thought: ``` --72548-- run: /usr/bin/dsymutil "/opt/local/lib/kde4/kcm_knote.so" --72548-- run: /usr/bin/dsymutil "/opt/local/lib/libknotesprivate.4.14.21.dylib" --72548-- run: /usr/bin/dsymutil "/opt/local/lib/libnoteshared.4.14.21.dylib" --72548-- run: /usr/bin/dsymutil "/opt/local/lib/libkdnssd.4.14.21.dylib" warning: (x86_64) /tmp/lto.o unable to open object file warning: no debug symbols in executable (-arch x86_64) ==72548== Invalid read of size 8 ==72548==at 0xCA796B9: Akonadi::AttributeFactory::registerAttribute(Akonadi::Attribute*) (attributefactory.cpp:148) ==72548==by 0x19ED63DE: global constructors keyed to a (attributefactory.h:61) ==72548==by 0x7FFF5FC11C6D: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==72548==by 0x7FFF5FC11DF9: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==72548==by 0x7FFF5FC0EAA1: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==72548==by 0x7FFF5FC0EA2A: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==72548==by 0x7FFF5FC0EA2A: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==72548==by 0x7FFF5FC0E935: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==72548==by 0x7FFF5FC04B0D: dyld::runInitializers(ImageLoader*) (in /usr/lib/dyld) ==72548==by 0x7FFF5FC0B80E: dlopen (in /usr/lib/dyld) ==72548==by 0x90657ED: dlopen (in /usr/lib/system/libdyld.dylib) ==72548==by 0x38F8AFC: QLibraryPrivate::load_sys() (in /opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore) ==72548== Address 0x1a48cd40 is not stack'd, malloc'd or (recently) free'd ==72548== *** KMail got signal 11 (Exiting) *** Dead letters dumped. KCrash: Application 'kontact' crashing... KCrash: Attempting to start /opt/local/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi directly ``` -- You are receiving this mail because: You are the assignee for the bug.
[kontact] [Bug 370646] Crash when opening Kontact preferences
https://bugs.kde.org/show_bug.cgi?id=370646 --- Comment #2 from RJVB --- Backtrace below. Among the things I tried was not deleting only attributes of type NoteDisplayAttribute. That actually made things worse, somehow, causing crashes even when the application was starting up. I do wonder about the delete, which appears to be a recent addition. QHash::insert doesn't make copies as far as I read its documentation, so why the delete? To allow the code registering an attribute to forget about it? Maybe libnoteshared registers attributes it then deletes itself? Application: Kontact (kontact), signal: Segmentation fault: 11 (lldb) process attach --pid 59010 Process 59010 stopped Executable module set to "/opt/local/bin/kontact". Architecture set to: x86_64-apple-macosx. (lldb) set set term-width 200 (lldb) thread info thread #1: tid = 0x354337, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x354337, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x000107fc616e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) + 286 frame #2: 0x000107fc5295 libkdeui.5.dylib`KCrash::defaultCrashHandler(int) + 1189 frame #3: 0x7fff8b6e15aa libsystem_platform.dylib`_sigtramp + 26 frame #4: 0x00010a5249ca libakonadi-kde.4.dylib`Akonadi::AttributeFactory::registerAttribute(this=0x7f97dbc28870, attr=0x7f97e1d8b980) + 538 at attributefactory.cpp:141 frame #5: 0x000120e3c2cf libnoteshared.4.dylib`_GLOBAL__I_a [inlined] void Akonadi::AttributeFactory::registerAttribute() + 47 at attributefactory.h:61 frame #6: 0x000120e3c2a4 libnoteshared.4.dylib`_GLOBAL__I_a [inlined] (anonymous namespace)::dummy() at attributeregistrar.cpp:30 frame #7: 0x000120e3c2a4 libnoteshared.4.dylib`_GLOBAL__I_a [inlined] __cxx_global_var_init at attributeregistrar.cpp:38 frame #8: 0x000120e3c2a4 libnoteshared.4.dylib`_GLOBAL__I_a + 4 at attributeregistrar.cpp:0 frame #9: 0x7fff61468c6e dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 268 frame #10: 0x7fff61468dfa dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40 frame #11: 0x7fff61465aa2 dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 308 frame #12: 0x7fff61465a2b dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 189 frame #13: 0x7fff61465a2b dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 189 frame #14: 0x7fff61465936 dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 54 frame #15: 0x7fff6145bb0e dyld`dyld::runInitializers(ImageLoader*) + 89 frame #16: 0x7fff6146280f dyld`dlopen + 538 frame #17: 0x7fff8eb347ee libdyld.dylib`dlopen + 59 frame #18: 0x00010981aafd QtCore`QLibraryPrivate::load_sys() + 2589 frame #19: 0x000109818000 QtCore`QLibrary::load() + 80 frame #20: 0x0001093b5281 libkdecore.5.dylib`KLibLoader::library(QString const&, QFlags) + 145 frame #21: 0x00010a0acb73 libkcmutils.4.dylib`KCModuleLoader::loadModule(KCModuleInfo const&, KCModuleLoader::ErrorReporting, QWidget*, QStringList const&) + 3635 frame #22: 0x00010a0b470c libkcmutils.4.dylib`KCModuleProxyPrivate::loadModule() + 668 frame #23: 0x00010a0b4432 libkcmutils.4.dylib`KCModuleProxy::realModule() const + 66 frame #24: 0x00010a0b0791 libkcmutils.4.dylib`KCMultiDialog::addModule(KCModuleInfo const&, KPageWidgetItem*, QStringList const&) + 385 frame #25: 0x00010a0caf6b libkcmutils.4.dylib`KSettings::DialogPrivate::createDialogFromServices() + 2715 frame #26: 0x00010a0ca053 libkcmutils.4.dylib`KSettings::Dialog::showEvent(QShowEvent*) + 1923 frame #27: 0x0001085ce1f6 QtGui`QWidget::event(QEvent*) + 1334 frame #28: 0x000108574afc QtGui`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 332 frame #29: 0x000108577e99 QtGui`QApplication::notify(QObject*, QEvent*) + 8281 frame #30: 0x000109830126 QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 118 frame #31: 0x0001085ccf0c QtGui`QWidgetPrivate::show_helper() + 668 frame #32: 0x0001085cd9ae QtGui`QWidget::setVisible(bool) + 974 frame #33: 0x000108a314b9 QtGui`QDialog::setVisible(bool) + 169 frame #34: 0x00010732b8fc libkontactprivate.4.dylib`Kontact::MainWindow::slotPreferences() [inlined] QWidget:
[kontact] [Bug 370646] New: Crash when opening Kontact preferences
https://bugs.kde.org/show_bug.cgi?id=370646 Bug ID: 370646 Summary: Crash when opening Kontact preferences Product: kontact Version: GIT (master) Platform: Compiled Sources OS: OS X Status: UNCONFIRMED Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Kontact built from the latest 4.14 branch sources crashes on OS X whenever I open the Kontact preferences dialog. Reproducible: Always Steps to Reproduce: 1. Start Kontact 2. Select Settings/Configure Kontact Actual Results: DrKonqi appears Expected Results: Kontact preferences dialog appears The actual crash is in line 141 of attributefactory.cpp (`AttributeFactory::registerAttribute(Attribute *attr)`): delete *it; For now I haven't seen it happen when I comment that line out; I hope this only leads to a minor memory leak (which I find preferable over a crash). I hope this info is useful for the KF5 version but would appreciate a backported fix. -- You are receiving this mail because: You are the assignee for the bug.
[Akonadi] [Bug 344970] Crash because uids.size()==1" in file ../../../resources/imap/retrieveitemtask.cpp, line 101
https://bugs.kde.org/show_bug.cgi?id=344970 --- Comment #4 from RJVB --- Looking at the code it seems that most of those Q_ASSERT statements can be replaced with a handler similar to the `if (!ok)` on line 120. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 344970] Crash because uids.size()==1" in file ../../../resources/imap/retrieveitemtask.cpp, line 101
https://bugs.kde.org/show_bug.cgi?id=344970 --- Comment #2 from RJVB --- Is there a patch for this in later versions that I could backport? -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 344970] Crash because uids.size()==1" in file ../../../resources/imap/retrieveitemtask.cpp, line 101
https://bugs.kde.org/show_bug.cgi?id=344970 --- Comment #1 from RJVB --- Created attachment 99213 --> https://bugs.kde.org/attachment.cgi?id=99213&action=edit New crash information added by DrKonqi akonadi_imap_resource (4.13) on KDE Platform 4.14.19 using Qt 4.8.7 - What I was doing when the application crashed: I opened the Spam folder of a GMail account and selected a message. I think the crash occurred before selecting the message or as an immediate result of that action. The last output from akonadi and kmail: akonadi_imap_resource_14(5671) ResourceState::item: Called item() while state holds multiple items! list is empty list is empty There is not valid message akonadi_imap_resource_14(5671) ResourceState::item: Called item() while state holds multiple items! akonadi_imap_resource_14(5671) ResourceState::item: Called item() while state holds multiple items! akonadi_imap_resource_14(5671) ResourceState::item: Called item() while state holds multiple items! akonadi_imap_resource_14(5671) ResourceState::item: Called item() while state holds multiple items! ASSERT: "uids.size()==1" in file ../../../resources/imap/retrieveitemtask.cpp, line 101 KCrash: Application 'akonadi_imap_resource' crashing... KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit KCrash: Connect sock_file=/home/bertin/.kde/socket-Patux/kdeinit4__0 -- Backtrace (Reduced): #6 0x7f08f8016c49 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #7 0x7f08f801a058 in __GI_abort () at abort.c:89 [...] #11 0x004610d1 in RetrieveItemTask::onMessagesReceived (this=0x204f0b0, mailBox=..., uids=..., messages=...) at ../../../resources/imap/retrieveitemtask.cpp:101 [...] #13 0x7f08fa76da28 in messagesReceived (this=0x1627, _t1=..., _t2=..., _t3=...) at ./moc_fetchjob.cpp:121 #14 KIMAP::FetchJobPrivate::emitPendings (this=0x2206ee0) at ../../kimap/fetchjob.cpp:60 -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 344970] Crash because uids.size()==1" in file ../../../resources/imap/retrieveitemtask.cpp, line 101
https://bugs.kde.org/show_bug.cgi?id=344970 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 359698] Wastebin does not get emptied when config set to empty on exit
https://bugs.kde.org/show_bug.cgi?id=359698 --- Comment #4 from RJVB --- The venom appears to be here Thread 1 (Thread 0x7f751218b940 (LWP 26483)): [KCrash Handler] #6 QListData::size (this=0x10) at /usr/include/qt5/QtCore/qlist.h:105 #7 QList::count (this=0x10) at /usr/include/qt5/QtCore/qlist.h:314 #8 KMail::UndoStack::size (this=0x0) at /usr/src/debug/kdepim-15.12.2/kmail/undostack.cpp:58 #9 0x7f7511a1247c in KMMainWidget::updateMessageActionsDelayed (this=this@entry=0xddef60) at /usr/src/debug/kdepim-15.12.2/kmail/kmmainwidget.cpp:3850 #10 0x7f7511a12d23 in KMMainWidget::updateMessageActions (this=this@entry=0xddef60, fast=fast@entry=false) at /usr/src/debug/kdepim-15.12.2/kmail/kmmainwidget.cpp:3682 #11 0x7f7511a23331 in KMMainWidget::setupActions (this=this@entry=0xddef60) at /usr/src/debug/kdepim-15.12.2/kmail/kmmainwidget.cpp:3423 #12 0x7f7511a277db in KMMainWidget::KMMainWidget (this=0xddef60, parent=, aGUIClient=0xea9ec0, actionCollection=0xce4930, config=...) at /usr/src/debug/kdepim-15.12.2/kmail/kmmainwidget.cpp:256 #13 0x7f75119d56d2 in KMMainWin::KMMainWin (this=0xea9e50, __in_chrg=, __vtt_parm=) at /usr/src/debug/kdepim-15.12.2/kmail/kmmainwin.cpp:61 #14 0x7f75119e6237 in KMKernel::openReader (this=this@entry=0x7ffec338fcc0, onlyCheck=onlyCheck@entry=false) at /usr/src/debug/kdepim-15.12.2/kmail/kmkernel.cpp:522 That looks like an attempt to determine the size of a non-existing undo stack -- maybe KMail detects the presence of messages in the wastebin and presumes this must mean that an undo stack has been created? -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 359698] Wastebin does not get emptied when config set to empty on exit
https://bugs.kde.org/show_bug.cgi?id=359698 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #1 from RJVB --- You should upload a backtrace for the crash, either through DrKonqi (which *should* appear when a KDE application crashes) or else by running kmail from within a debugger (type `gdb --args /usr/bin/kmail --nofork` or something like that in a terminal, and then `bt` [without the quotes] when the crash occurs) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kontact] [Bug 359236] kontact crash after disabling the knode (usenet) component
https://bugs.kde.org/show_bug.cgi?id=359236 --- Comment #2 from RJVB --- No more Usenet reader in KF5 PIM? If so, that's a perfect reason not to bother with it ... -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kontact] [Bug 359236] New: kontact crash after disabling the knode (usenet) component
https://bugs.kde.org/show_bug.cgi?id=359236 Bug ID: 359236 Summary: kontact crash after disabling the knode (usenet) component Product: kontact Version: unspecified Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Application: kontact (4.13.3) KDE Platform Version: 4.14.14 (Compiled from sources) Qt Version: 4.8.7 Operating System: Linux 3.14.59-ck1-mainline-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.3 LTS -- Information about the crash: - What I was doing when the application crashed: 1) started knode --nofork from a terminal 2) started kontact --nofork from a terminal worked for a while, then quit knode as it became stuck trying to update my subscribed newsgroups 3) restarted knode --nofork from a terminal after noticing that opened knode in the running kontact process, I went to the Kontact settings and deactivated knode. Some time after that, this crash occurred. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fdb0be2e800 (LWP 880))] Thread 5 (Thread 0x7fdaebd25700 (LWP 882)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fdb0697a81d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7fdb0697a859 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7fdb030a3182 in start_thread (arg=0x7fdaebd25700) at pthread_create.c:312 #4 0x7fdb0905347d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 4 (Thread 0x7fdaab40a700 (LWP 883)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fdb066bb20d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7fdb069a9fd6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7fdb030a3182 in start_thread (arg=0x7fdaab40a700) at pthread_create.c:312 #4 0x7fdb0905347d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7fda9a9af700 (LWP 907)): #0 0x7fdb0904482d in read () at ../sysdeps/unix/syscall-template.S:81 #1 0x7fdb02c04c10 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fdb02bc3b14 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fdb02bc3f7b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fdb02bc40ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fdb0996828e in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #6 0x7fdb09a1eeef in QEventLoop::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #7 0x7fdb09a20db6 in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x7fdb09900669 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #9 0x7fdb09900306 in QThreadPrivate::start(void*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #10 0x7fdb030a3182 in start_thread (arg=0x7fda9a9af700) at pthread_create.c:312 #11 0x7fdb0905347d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7fda88d03700 (LWP 13610)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fda9d72a9a4 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #2 0x7fda9d72a9e9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #3 0x7fdb030a3182 in start_thread (arg=0x7fda88d03700) at pthread_create.c:312 #4 0x7fdb0905347d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7fdb0be2e800 (LWP 880)): [KCrash Handler] #6 0x7fdb0a5dc8e8 in QWidget::window() const () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #7 0x7fda83cf1375 in topLevelWidget (this=, this=) at /usr/include/qt4/QtGui/qwidget.h:328 #8 KNMainWidget::setStatusMsg (this=0xa697600, text=..., id=405) at ../../knode/knmainwidget.cpp:263 #9 0x7fda83c691c6 in KNGroup::scoreArticles (this=0xb4a80d0, onlynew=) at ../../knode/kngroup.cpp:923 #10 0x7fda83c57881 in KNGroupManager::processJob (this=0xb241a40, j=0xb3f2a80) at ../../knode/kngroupmanager.cpp:630 #11 0x7fda83c40ddf in KNode::Scheduler::slotJobFinished (this=0x3df8730, job=0xb3f2a80) at ../../knode/scheduler.cpp:202 #12 0x7fda83d5c91d in KNode::Scheduler::qt_static_metacall (_o=0x3df8730, _c=, _id=, _a=0x7ffc2e359710) at ./moc_scheduler.cpp:57 #13 0x7fdb09a3c686 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #14 0x7fda8
[kmail2] [Bug 355278] New: gmail messages can remain as "ghosts" after deletion
https://bugs.kde.org/show_bug.cgi?id=355278
Bug ID: 355278
Summary: gmail messages can remain as "ghosts" after deletion
Product: kmail2
Version: 4.14.7
Platform: Compiled Sources
OS: All
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: message list
Assignee: kdepim-bugs@kde.org
Reporter: rjvber...@gmail.com
As reported (elsewhere?) already, there are cases where deleted messages from a
GMail account are not actually deleted at all, and remain as "ghosts",
greyed-out entries in kmail's message list that cannot be selected.
I just discovered that this also happens with entries in the Drafts folder,
after sending them.
Reproducible: Always
Steps to Reproduce:
1. configure a gmail account with the corresponding draft and wastebin ("Bin")
folders
2a. write and send a message
3a. delete any message from the active folder *before* having received the
notification that the message from (2) was sent successfully
OR
2b. compose a message, save it to the Drafts folder
3b. double-click to open it, and then send it.
4. select another folder, and then re-select the previous folder (this may need
to be done a few times)
Actual Results:
The message deleted under 3a. or sent under 3b. will reappear in the list, but
ghosted. It can no longer be selected.
Expected Results:
The message is supposed to have been deleted, so it should not reappear.
- this also applies to selections of multiple messages, in the 4.13 and 4.14
series on both Linux and OS X
- checking via GMail's web interface or a different client, the ghost messages
are indeed not deleted at all
- The effect of 3a. can be undone (*before* selecting another folder) by
hitting undo (^Z), waiting for the message to reappear as "not deleted", and
then deleting it again. After any message sending has completed of course.
- The effect can also be undone in akonadiconsole:
1. go to the folder in the browser tab
2. select the message: its attributes will show "/DELETED"
3. right-click the message, and *move* it to the account's Bin folder
Cleanup is a major feature IMHO, hence the Major severity I assigned to this
ticket.
--
You are receiving this mail because:
You are the assignee for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kimap] [Bug 352883] New: remote changes to message read/important state on gmail imap account aren't synced
https://bugs.kde.org/show_bug.cgi?id=352883 Bug ID: 352883 Summary: remote changes to message read/important state on gmail imap account aren't synced Product: kimap Version: git Platform: Compiled Sources OS: All Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Recent kdepim* 4.14 has a regression in which remote changes to message read and/or "important" (starred) states are not always synced reliably. I generally run into this issue coming back to kmail on Mac OS X after having used kmail 4.13.3 on a Linux host, but when it strikes, one can login to gmail's web interface, and toggle the read state of a whole thread without that this change is reflected in the running kmail instance. akonadi 1.13.1 commit 9c0dc6b kdepimlibs v4.14.10-16-g2e7d344 kdepim v4.14.10-7-g48cfa63 kdepim-runtime v4.14.10 commit b3bfa11 this issue does NOT occur when using KDE PIM (libs and runtime included) 4.13.3 (release) with the same akonadi version. Reproducible: Sometimes Steps to Reproduce: 1. install the kdepimlibs, kdepim-runtime and kdepim versions cited in the summary 2. define an imap account hosted on GMail and open one of its folders in kmail2 3. induce a read state change outside of kmail, for instance through gmail's web interface 4. induce an "important" state change the same way (click the star) Actual Results: Sometimes the state is synced correctly, sometimes it isn't. I have not yet found a way to make it sync when it doesn't (restarting kmail and all agents does NOT help), and haven't yet had the patience to wait to see if it settles itself in time. kmail DOES SHOW a progress indicator suggesting that a sync takes place as soon as I activate the window after effectuating a change via gmail.com , so IMAP IDLE apparently works to some extent. Expected Results: Messages are shown as (un)read and/or (un)important as a function of settings made outside of the running kmail instance, be it via kmail on another host or via the gmail.com website. This information is updated as soon as it becomes available, through IMAP IDLE or a scheduled or manual sync. Reverting to kde pim release 4.13.3 restores proper behaviour without a change in the akonadi version. Inquiry on the kdepim-users ML showed that at least 1 other user is concerned, apparently on OpenSuse. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 328601] Callbacks to ResourceTasks with an invalid state can lead to crashes
https://bugs.kde.org/show_bug.cgi?id=328601 --- Comment #16 from RJVB --- Created attachment 94467 --> https://bugs.kde.org/attachment.cgi?id=94467&action=edit New crash information added by DrKonqi akonadi_imap_resource (4.13) on KDE Platform 4.14.11 using Qt 4.8.7 - What I was doing when the application crashed: Kontact had been waiting for me to enter my wallet password for an unknown time (cats woke the computer from sleep); after I unlocked the situation I got this crash. -- Backtrace (Reduced): #6 0x7efd5df59524 in QObject::thread() const () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #7 0x7efd5df6012b in QObject::QObject(QObject*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x7efd5aa348fd in KJob::KJob (this=0x2a75a70, parent=0x40807) at ../../kdecore/jobs/kjob.cpp:51 #9 0x7efd5cb66d43 in KIMAP::Job::Job (this=0x2a75a70, dd=...) at ../../kimap/job.cpp:37 #10 0x7efd5cb7e4d7 in KIMAP::SelectJob::SelectJob (this=0x2a75a70, session=) at ../../kimap/selectjob.cpp:60 -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 328601] Callbacks to ResourceTasks with an invalid state can lead to crashes
https://bugs.kde.org/show_bug.cgi?id=328601 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 350559] New: IMAP resource crash after wake-from-sleep
https://bugs.kde.org/show_bug.cgi?id=350559 Bug ID: 350559 Summary: IMAP resource crash after wake-from-sleep Product: Akonadi Version: 4.13 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: rjvber...@gmail.com CC: kdepim-bugs@kde.org, vkra...@kde.org Application: akonadi_imap_resource (4.13) KDE Platform Version: 4.14.7 (Compiled from sources) Qt Version: 4.8.7 Operating System: Linux 3.14.46-ck1-mainline-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.2 LTS -- Information about the crash: - What I was doing when the application crashed: I woke the computer from sleep, unlocked the KDE wallet when requested, and then connected to the preferred WiFi hotspot (for some reason, the system connects to the weaker of my 2 WiFi networks first, half the time). -- Backtrace: Application: RJVB@mw of type IMAP E-Mail Server (akonadi_imap_resource), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f4e41f087c0 (LWP 4502))] Thread 4 (Thread 0x7f4e2d051700 (LWP 4595)): #0 0x7f4e3bf4561a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f4e3bf45979 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f4e3bf03699 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f4e3bf03f03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f4e3bf040ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f4e412a128e in QEventDispatcherGlib::processEvents (this=0x7f4e280008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #6 0x7f4e4126c66f in QEventLoop::processEvents (this=this@entry=0x7f4e2d050e20, flags=...) at kernel/qeventloop.cpp:149 #7 0x7f4e4126c9b5 in QEventLoop::exec (this=this@entry=0x7f4e2d050e20, flags=...) at kernel/qeventloop.cpp:204 #8 0x7f4e41150a8d in QThread::exec (this=) at thread/qthread.cpp:538 #9 0x7f4e41153803 in QThreadPrivate::start (arg=0x2407330) at thread/qthread_unix.cpp:352 #10 0x7f4e3c82d182 in start_thread (arg=0x7f4e2d051700) at pthread_create.c:312 #11 0x7f4e3d40847d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7f4e25e00700 (LWP 7703)): #0 0x7f4e3c8307ee in __pthread_mutex_unlock_usercnt (decr=1, mutex=0x7f4e14005320) at pthread_mutex_unlock.c:57 #1 __GI___pthread_mutex_unlock (mutex=0x7f4e14005320) at pthread_mutex_unlock.c:310 #2 0x7f4e3bf459b1 in g_mutex_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f4e3bf03a59 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f4e3bf03f7b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f4e3bf040ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x7f4e412a128e in QEventDispatcherGlib::processEvents (this=0x7f4e140053e0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #7 0x7f4e4126c66f in QEventLoop::processEvents (this=this@entry=0x7f4e25dffe20, flags=...) at kernel/qeventloop.cpp:149 #8 0x7f4e4126c9b5 in QEventLoop::exec (this=this@entry=0x7f4e25dffe20, flags=...) at kernel/qeventloop.cpp:204 #9 0x7f4e41150a8d in QThread::exec (this=) at thread/qthread.cpp:538 #10 0x7f4e41153803 in QThreadPrivate::start (arg=0x2398350) at thread/qthread_unix.cpp:352 #11 0x7f4e3c82d182 in start_thread (arg=0x7f4e25e00700) at pthread_create.c:312 #12 0x7f4e3d40847d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f4e24dfe700 (LWP 25026)): #0 0x7f4e3bf4561d in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f4e3bf45979 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f4e3bf03557 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f4e3bf03f03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f4e3bf040ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f4e412a128e in QEventDispatcherGlib::processEvents (this=0x7f4e0c011d60, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #6 0x7f4e4126c66f in QEventLoop::processEvents (this=this@entry=0x7f4e24dfde20, flags=...) at kernel/qeventloop.cpp:149 #7 0x7f4e4126c9b5 in QEventLoop::exec (this=this@entry=0x7f4e24dfde20, flags=...) at kernel/qeventloop.cpp:204 #8 0x7f4e41150a8d in QThread::exec (this=) at thread/qthread.cpp:538 #9 0x7f4e41153803 in QThreadPrivate::start (arg=0x2418f50) at thread/qthread_unix.cpp:352 #10 0x7f4e3c82d182 in start_thread (arg=0x7f4e24dfe700) at pthread_create.c:312 #11 0x7f4e3d40847d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:1
[kontact] [Bug 340680] another crash-on-exit due to nested event handling
https://bugs.kde.org/show_bug.cgi?id=340680 --- Comment #3 from RJVB --- Created attachment 92528 --> https://bugs.kde.org/attachment.cgi?id=92528&action=edit patch set *against KDEPIM 4.13.3* This is the set of patches I'm running with KDE PIM 4.13.3 since shortly after I created this bug report. I haven't looked back since, so I don't know if the 4.14 series has become as stable as 4.13.3, but that earlier version works so good (on Linux and OS X) that I have no incentive to upgrade for the sake of upgrading. The check against kmkernel->shuttingDown() is among the changes. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 346064] New: imap mail agent assertion failure/crash at wake
https://bugs.kde.org/show_bug.cgi?id=346064 Bug ID: 346064 Summary: imap mail agent assertion failure/crash at wake Product: Akonadi Version: 4.13 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: rjvber...@gmail.com CC: kdepim-bugs@kde.org, vkra...@kde.org Application: akonadi_imap_resource (4.13) KDE Platform Version: 4.14.4 (Compiled from sources) Qt Version: 4.8.6 Operating System: Linux 3.13.11.15-ckt15-ck1-kubuntu-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.2 LTS -- Information about the crash: - What I was doing when the application crashed: I woke the computer after it had been suspended for the night. Sadly I cannot find the assertion message that must have been printed (drowned in too much other output). -- Backtrace: Application: RJVB@gmail of type IMAP E-Mail Server (akonadi_imap_resource), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f8b577ee7c0 (LWP 5236))] Thread 13 (Thread 0x7f8b4259e700 (LWP 32751)): #0 pthread_mutex_lock (mutex=0x7f8b3401f790) at forward.c:192 #1 0x7f8b517fe981 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8b517bc699 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f8b517bcf03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f8b517bd0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f8b56b861ee in QEventDispatcherGlib::processEvents (this=0x7f8b3401a7c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #6 0x7f8b56b5204f in QEventLoop::processEvents (this=this@entry=0x7f8b4259de20, flags=...) at kernel/qeventloop.cpp:149 #7 0x7f8b56b52395 in QEventLoop::exec (this=this@entry=0x7f8b4259de20, flags=...) at kernel/qeventloop.cpp:204 #8 0x7f8b56a3496d in QThread::exec (this=) at thread/qthread.cpp:538 #9 0x7f8b56a375a3 in QThreadPrivate::start (arg=0x1296100) at thread/qthread_unix.cpp:349 #10 0x7f8b520e6182 in start_thread (arg=0x7f8b4259e700) at pthread_create.c:312 #11 0x7f8b52cc247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 12 (Thread 0x7f8b3affd700 (LWP 18607)): #0 0x7f8b517fe61a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f8b517fe979 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8b517bced5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f8b517bd0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f8b56b861ee in QEventDispatcherGlib::processEvents (this=0x7f8b2c028ee0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #5 0x7f8b56b5204f in QEventLoop::processEvents (this=this@entry=0x7f8b3affce20, flags=...) at kernel/qeventloop.cpp:149 #6 0x7f8b56b52395 in QEventLoop::exec (this=this@entry=0x7f8b3affce20, flags=...) at kernel/qeventloop.cpp:204 #7 0x7f8b56a3496d in QThread::exec (this=) at thread/qthread.cpp:538 #8 0x7f8b56a375a3 in QThreadPrivate::start (arg=0x118cf50) at thread/qthread_unix.cpp:349 #9 0x7f8b520e6182 in start_thread (arg=0x7f8b3affd700) at pthread_create.c:312 #10 0x7f8b52cc247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 11 (Thread 0x7f8b3bfff700 (LWP 22955)): #0 0x7f8b52cb511d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f8b517bcfe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f8b517bd0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f8b56b861ee in QEventDispatcherGlib::processEvents (this=0x7f8b30003c60, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #4 0x7f8b56b5204f in QEventLoop::processEvents (this=this@entry=0x7f8b3bffee20, flags=...) at kernel/qeventloop.cpp:149 #5 0x7f8b56b52395 in QEventLoop::exec (this=this@entry=0x7f8b3bffee20, flags=...) at kernel/qeventloop.cpp:204 #6 0x7f8b56a3496d in QThread::exec (this=) at thread/qthread.cpp:538 #7 0x7f8b56a375a3 in QThreadPrivate::start (arg=0xfff740) at thread/qthread_unix.cpp:349 #8 0x7f8b520e6182 in start_thread (arg=0x7f8b3bfff700) at pthread_create.c:312 #9 0x7f8b52cc247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 10 (Thread 0x7f8b3b7fe700 (LWP 25176)): #0 0x7fff0ddf97c8 in clock_gettime () #1 0x7f8b52cd092d in __GI___clock_gettime (clock_id=, tp=) at ../sysdeps/unix/clock_gettime.c:115 #2 0x7f8b56a97229 in do_gettime (frac=, sec=) at tools/qelapsedtimer_unix.cpp:127 #3 qt_gettime () at tools/qelapsedtimer_unix.cpp:144 #4 0x7f8b56b87015 in updateCurrentTime (this=0x7f8b28002130) at kernel/qeventdispatcher_unix.cpp:354 #5 QTim
[kmail2] [Bug 345396] New: Replying to or forwarding a signed/encrypted message can block the whole application
https://bugs.kde.org/show_bug.cgi?id=345396 Bug ID: 345396 Summary: Replying to or forwarding a signed/encrypted message can block the whole application Product: kmail2 Version: 4.13.3 Platform: MacPorts Packages OS: OS X Status: UNCONFIRMED Severity: crash Priority: NOR Component: composer Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Replying to or forwarding a message that was signed (or encrypted) with an unknown key can block the whole application for minutes, as if it's "hung", while the keyserver is queried. Reproducible: Always Steps to Reproduce: 1. Receive a message signed or encrypted with a key that is not known locally 2. Select the message in the message list 3. Hit 'f' (F) or r to forward the message or reply to it Actual Results: On OS X, the "beachball of death" appears quickly without any other sign of progress, indicating that the application is no longer handling events. If the configured keyserver is slow to respond for whatever reason, this situation persists until the lookup succeeds, fails on the server, or times out. It is only at that time that the composer window opens. Expected Results: When selecting the message in step 2), its contents are shown in the viewer pane (if it's just signed, of course). The key lookup and ensuing validation take place in the background. The same thing should happen when replying or forwarding; I see no need to wait for validation. In any case the application shouldn't hang, and provide a way to interrupt the ongoing lookup (probably just by closing the composer window). I'm marking this as "software hangs" because I have no way to be sure that the software will NOT hang if the keyserver never replies. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 344970] New: Crash because uids.size()==1" in file ../../../resources/imap/retrieveitemtask.cpp, line 101
https://bugs.kde.org/show_bug.cgi?id=344970 Bug ID: 344970 Summary: Crash because uids.size()==1" in file ../../../resources/imap/retrieveitemtask.cpp, line 101 Product: Akonadi Version: 4.13 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: rjvber...@gmail.com CC: kdepim-bugs@kde.org, vkra...@kde.org Application: akonadi_imap_resource (4.13) KDE Platform Version: 4.14.4 (Compiled from sources) Qt Version: 4.8.6 Operating System: Linux 3.13.11.8-ck1-kubuntu-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.2 LTS -- Information about the crash: - What I was doing when the application crashed: I was simply trying to move to the next unread email message when I first got an "account is offline" warning and then this crash. Isn't there a more elegant way to handle the condition in a release/production version than crashing through a Q_ASSERT?! -- Backtrace: Application: RJVB@gmail of type IMAP E-Mail Server (akonadi_imap_resource), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fcd1a3457c0 (LWP 14505))] Thread 9 (Thread 0x7fcd05572700 (LWP 25271)): #0 0x7fff4a7dbcf8 in clock_gettime () #1 0x7fcd1589392d in __GI___clock_gettime (clock_id=, tp=) at ../sysdeps/unix/clock_gettime.c:115 #2 0x7fcd195ec229 in do_gettime (frac=, sec=) at tools/qelapsedtimer_unix.cpp:127 #3 qt_gettime () at tools/qelapsedtimer_unix.cpp:144 #4 0x7fcd196dc015 in updateCurrentTime (this=0x7fccf8003320) at kernel/qeventdispatcher_unix.cpp:354 #5 QTimerInfoList::timerWait (this=0x7fccf8003320, tm=...) at kernel/qeventdispatcher_unix.cpp:460 #6 0x7fcd196da747 in timerSourcePrepareHelper (src=, timeout=0x7fcd05571c64) at kernel/qeventdispatcher_glib.cpp:143 #7 0x7fcd196da825 in timerSourcePrepare (source=, timeout=) at kernel/qeventdispatcher_glib.cpp:176 #8 0x7fcd1437f68d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x7fcd1437ff03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x7fcd143800ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7fcd196db1ee in QEventDispatcherGlib::processEvents (this=0x7fccf80221c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #12 0x7fcd196a704f in QEventLoop::processEvents (this=this@entry=0x7fcd05571e20, flags=...) at kernel/qeventloop.cpp:149 #13 0x7fcd196a7395 in QEventLoop::exec (this=this@entry=0x7fcd05571e20, flags=...) at kernel/qeventloop.cpp:204 #14 0x7fcd1958996d in QThread::exec (this=) at thread/qthread.cpp:538 #15 0x7fcd1958c5a3 in QThreadPrivate::start (arg=0x18871b0) at thread/qthread_unix.cpp:349 #16 0x7fcd14ca9182 in start_thread (arg=0x7fcd05572700) at pthread_create.c:312 #17 0x7fcd1588547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 8 (Thread 0x7fccfe3d2700 (LWP 31627)): #0 0x7fcd14cab569 in __GI___pthread_mutex_lock (mutex=0x7fccec00d180) at ../nptl/pthread_mutex_lock.c:125 #1 0x7fcd143c1981 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fcd1437f699 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fcd1437ff03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fcd143800ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fcd196db1ee in QEventDispatcherGlib::processEvents (this=0x7fccec0122b0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #6 0x7fcd196a704f in QEventLoop::processEvents (this=this@entry=0x7fccfe3d1e20, flags=...) at kernel/qeventloop.cpp:149 #7 0x7fcd196a7395 in QEventLoop::exec (this=this@entry=0x7fccfe3d1e20, flags=...) at kernel/qeventloop.cpp:204 #8 0x7fcd1958996d in QThread::exec (this=) at thread/qthread.cpp:538 #9 0x7fcd1958c5a3 in QThreadPrivate::start (arg=0x18458b0) at thread/qthread_unix.cpp:349 #10 0x7fcd14ca9182 in start_thread (arg=0x7fccfe3d2700) at pthread_create.c:312 #11 0x7fcd1588547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 7 (Thread 0x7fccff235700 (LWP 5212)): #0 0x7fcd1587682d in read () at ../sysdeps/unix/syscall-template.S:81 #1 0x7fcd143c0c10 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fcd1437fb14 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fcd1437ff7b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fcd143800ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fcd196db1ee in QEventDispatcherGlib::processEvents (this=0x7fccf400bb80, flags=...) at kernel/qeventdispatcher_glib.cpp
[Akonadi] [Bug 343476] New: git origin/1.13 searchtest.cpp fails to build with clang
https://bugs.kde.org/show_bug.cgi?id=343476
Bug ID: 343476
Summary: git origin/1.13 searchtest.cpp fails to build with
clang
Product: Akonadi
Version: GIT (master)
Platform: Compiled Sources
OS: other
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: server
Assignee: kdepim-bugs@kde.org
Reporter: rjvber...@gmail.com
clang 3.5 fails to build searchtest.cpp from the 1.13 branch head:
akonadi-1.13.1/server/tests/unittest/searchtest.cpp:124:30: error: no matching
conversion for functional-style cast from 'void' to 'QVector'
<< QVector({ col4.id(), col5.id(), col7.id()
});
^~~
/opt/local/include/qt4/QtCore/qvector.h:121:14: note: candidate constructor not
viable: cannot convert initializer list argument to 'int'
explicit QVector(int size);
^
/opt/local/include/qt4/QtCore/qvector.h:123:12: note: candidate constructor not
viable: cannot convert initializer list argument to 'const QVector'
inline QVector(const QVector &v) : d(v.d) { d->ref.ref(); if
(!d->sharable) detach_helper(); }
^
/opt/local/include/qt4/QtCore/qvector.h:120:12: note: candidate constructor not
viable: requires 0 arguments, but 1 was provided
inline QVector() : d(&QVectorData::shared_null) { d->ref.ref(); }
^
/opt/local/include/qt4/QtCore/qvector.h:122:5: note: candidate constructor not
viable: requires 2 arguments, but 1 was provided
QVector(int size, const T &t);
^
Reproducible: Always
Steps to Reproduce:
1. checkout akonadi git c733429f
2. cmake -DCMAKE_CXX_COMPILER=clang (etc)
3. make
Actual Results:
akonadi-1.13.1/server/tests/unittest/searchtest.cpp:124:30: error: no matching
conversion for functional-style cast from 'void' to 'QVector'
<< QVector({ col4.id(), col5.id(), col7.id()
});
^~~
/opt/local/include/qt4/QtCore/qvector.h:121:14: note: candidate constructor not
viable: cannot convert initializer list argument to 'int'
explicit QVector(int size);
^
/opt/local/include/qt4/QtCore/qvector.h:123:12: note: candidate constructor not
viable: cannot convert initializer list argument to 'const QVector'
inline QVector(const QVector &v) : d(v.d) { d->ref.ref(); if
(!d->sharable) detach_helper(); }
^
/opt/local/include/qt4/QtCore/qvector.h:120:12: note: candidate constructor not
viable: requires 0 arguments, but 1 was provided
inline QVector() : d(&QVectorData::shared_null) { d->ref.ref(); }
^
/opt/local/include/qt4/QtCore/qvector.h:122:5: note: candidate constructor not
viable: requires 2 arguments, but 1 was provided
QVector(int size, const T &t);
^
plus similar errors in the same file
Expected Results:
no errors
This error exists only in searchtest.cpp; tested both on OS X 10.9 and KUbuntu
14.04 with clang 3.5 .
--
You are receiving this mail because:
You are the assignee for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 319776] Akonadi crashed, possibly because of sudden lack of network connection, caused by the laptop going into suspend-to-ram
https://bugs.kde.org/show_bug.cgi?id=319776 --- Comment #26 from RJVB --- Created attachment 90401 --> https://bugs.kde.org/attachment.cgi?id=90401&action=edit New crash information added by DrKonqi akonadi_imap_resource (4.13) on KDE Platform 4.14.4 using Qt 4.8.6 - What I was doing when the application crashed: Woke the computer from sleep. It's surprising this bug is still not fixed... -- Backtrace (Reduced): #6 0x7f77cfcacc75 in QObject::disconnect (sender=0x1a4faf0, signal=0x1dd4149 "stateChanged(KIMAP::Session::State,KIMAP::Session::State)", receiver=0x1c9a5a0, method=0x1dd2d29 "onSessionStateChanged(KIMAP::Session::State,KIMAP::Session::State)") at kernel/qobject.cpp:2982 #7 0x0046c01c in SessionPool::killSession (this=0x1c9a5a0, session=0x1a4faf0, termination=SessionPool::LogoutSession) at ../../../resources/imap/sessionpool.cpp:181 #8 0x0046ba04 in SessionPool::disconnect (this=0x1c9a5a0, termination=SessionPool::LogoutSession) at ../../../resources/imap/sessionpool.cpp:115 #9 0x0041b827 in ImapResource::startConnect (this=0x1f76070) at ../../../resources/imap/imapresource.cpp:302 #10 0x00443188 in ImapResource::qt_static_metacall (_o=_o@entry=0x1f76070, _c=, _id=, _a=_a@entry=0x7fffc315ce30) at ./moc_imapresource.cpp:117 -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340046] after long inactivity (sleep) mailfilter agent remains at 0% indefinitely (and kmail at "Retrieving folder contents")
https://bugs.kde.org/show_bug.cgi?id=340046 --- Comment #3 from RJVB --- Unlikely. I don't have any offline features configured (one of the reasons in fact why I'm using kmail on OS X ...) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 25755] kmail external editor behaviour
https://bugs.kde.org/show_bug.cgi?id=25755 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #12 from RJVB --- I think Anthony described how to make the "fix" complete and probably acceptable for everyone: https://bugs.kde.org/show_bug.cgi?id=25755#c7 ... -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 340727] New: messages deleted from IMAP account (GMail) can end up in the local wastebin
https://bugs.kde.org/show_bug.cgi?id=340727 Bug ID: 340727 Summary: messages deleted from IMAP account (GMail) can end up in the local wastebin Product: kmail2 Version: unspecified Platform: Other OS: All Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Under certain conditions (IMAP account offline or not responding or ...?) it can happen that messages deleted from GMail accounts end up in my local wastebin rather than being moved to the configured wastebin folder on the server. When this happens, they remain "greyed out" in the folder they originate from even when they have been removed from the local wastebin, for an indefinite amount of time (= I have to connect through the web interface to delete them there). Sadly I cannot say how to reproduce the issue. Reproducible: Sometimes Steps to Reproduce: 1. Use a gmail account in a real-world usage scenario, which includes deleting (selections of) messages while syncs are going on, etc. 2. Notice unread/unseen messages signalled in the otherwise unused KMail Folders "account", that this concerns the wastebin, and also notice that those same messages are greyed-out in their original folder 3. empty the local wastebin in an attempt to remove those greyed-out messages Actual Results: Local wastebin is emptied but messages apparently remain on the server, untouchable. Expected Results: In fact, I'd expect that "Move to wastebin" and its keyboard shortcut move messages to the configured wastebin, or not at all (i.e. defer/queue the action) when that is not possible immediately, for whatever reason. It would be OK to post a dialog "Cannot move message[s] to the configured wastebin, $FOLDER, because $ERROR. Do you want to move it/them to a fallback wastebin?". At least the user knows what's going on like that. I'm marking this a major issue because of the unpredictable non-respect of a user setting. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kontact] [Bug 340680] New: another crash-on-exit due to nested event handling
https://bugs.kde.org/show_bug.cgi?id=340680
Bug ID: 340680
Summary: another crash-on-exit due to nested event handling
Product: kontact
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: kdepim-bugs@kde.org
Reporter: rjvber...@gmail.com
Application: kontact (4.14.3)
KDE Platform Version: 4.14.2 (Compiled from sources)
Qt Version: 4.8.6
Operating System: Linux 3.13.11.6-ck1-kubuntu-amdf10-rjvb x86_64
Distribution: Ubuntu 14.04.1 LTS
-- Information about the crash:
- What I was doing when the application crashed:
Yet again KMail had gotten stuck in the RFC ("Retrieving Folder Contents"
screen), so I Quit the application hoping to test my patch to the systray icon
from yesterday a bit more.
Didn't get the chance: turns out there is another nested event loop code path
to accessing a released resource: see the backtrace.
I am currently testing a patch for this on OS X (a check against
kmkernel->shuttingDown() at an appropriate place), but the best protection
against this kind of bug would be a switch to turn off all UI event handling
(if fixing KJob::exec doesn't cut it).
kdepim is built from source here, using git/4.14 from a bit under 24h ago (see
ppa:rjvbertin/kdepim)
-- Backtrace:
Application: Kontact (kontact), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
To enable execution of this file add
add-auto-load-safe-path
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20-gdb.py
line to your configuration file "/home/bertin/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/bertin/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Current thread is 1 (Thread 0x7f56e45f2800 (LWP 5030))]
Thread 5 (Thread 0x7f56c4e83700 (LWP 5032)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x7f56df22081d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#2 0x7f56df220859 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#3 0x7f56db902182 in start_thread (arg=0x7f56c4e83700) at
pthread_create.c:312
#4 0x7f56e1860fbd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 4 (Thread 0x7f5684568700 (LWP 5033)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x7f56def6120d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#2 0x7f56df24ffd6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4
#3 0x7f56db902182 in start_thread (arg=0x7f5684568700) at
pthread_create.c:312
#4 0x7f56e1860fbd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 3 (Thread 0x7f5674c47700 (LWP 5037)):
#0 0x7f56db46461a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x7f56db4649a9 in g_mutex_unlock () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x7f56db422680 in g_main_context_prepare () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x7f56db422f03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7f56db4230ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x7f56e221972e in QEventDispatcherGlib::processEvents
(this=0x7f5678c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#6 0x7f56e21e75af in QEventLoop::processEvents
(this=this@entry=0x7f5674c46de0, flags=...) at kernel/qeventloop.cpp:149
#7 0x7f56e21e78ed in QEventLoop::exec (this=this@entry=0x7f5674c46de0,
flags=...) at kernel/qeventloop.cpp:204
#8 0x7f56e20ca413 in QThread::exec (this=) at
thread/qthread.cpp:538
#9 0x7f56e20cce03 in QThreadPrivate::start (arg=0xec3f90) at
thread/qthread_unix.cpp:349
#10 0x7f56db902182 in start_thread (arg=0x7f5674c47700) at
pthread_create.c:312
#11 0x7f56e1860fbd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 2 (Thread 0x7f5669406700 (LWP 9424)):
#0 0x7f56db46461a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x7f56db464979 in g_mutex_lock () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x7f56db422a6c in g_main_context_check () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x7f56db422f7b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7f56db4230ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x7f56e221972e in QEventDispatcherGlib::processEvents
(this=0x7f5664006a90, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#6 0x7f56e21e75af in QEvent
[kontact] [Bug 340624] kontact won't exit and then crashes
https://bugs.kde.org/show_bug.cgi?id=340624 RJVB changed: What|Removed |Added Latest Commit||http://commits.kde.org/kdep ||im/dee0b2510ea1333aed5c7c8d ||673327c08019e3e1 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from RJVB --- Git commit dee0b2510ea1333aed5c7c8d673327c08019e3e1 by René J.V. Bertin. Committed on 05/11/2014 at 12:46. Pushed by rjvbb into branch 'KDE/4.14'. don't handle events for systray when shutting down, avoiding null pointer dereference and crash REVIEW: 120999 M +1-1kmail/kmsystemtray.cpp http://commits.kde.org/kdepim/dee0b2510ea1333aed5c7c8d673327c08019e3e1 -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kontact] [Bug 340624] kontact won't exit and then crashes
https://bugs.kde.org/show_bug.cgi?id=340624 --- Comment #2 from RJVB --- Comment on attachment 89443 --> https://bugs.kde.org/attachment.cgi?id=89443 I'm currently testing this patch, which should at least prevent the crash that should be kmkernel->shuttingDown() of course ... -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kontact] [Bug 340624] kontact won't exit and then crashes
https://bugs.kde.org/show_bug.cgi?id=340624 --- Comment #1 from RJVB --- Created attachment 89443 --> https://bugs.kde.org/attachment.cgi?id=89443&action=edit I'm currently testing this patch, which should at least prevent the crash -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 340625] New: imap parent folder properties regression (git/4.14)
https://bugs.kde.org/show_bug.cgi?id=340625 Bug ID: 340625 Summary: imap parent folder properties regression (git/4.14) Product: kmail2 Version: Git (master) Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: folders Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Until recently it was possible to set certain properties (retrieve frequency) of a collection of IMAP folders by editing the properties of the parent folder, be it the account entry in the folder list, or a parent folder like "[Google Mail]". It seems that this is still possible for "regular" folders (like the "Devel" folder under which I have gmail store folders for KDE, MacPorts etc. mailinglists), but it no longer is for "[Google Mail]" or the account entry. Reproducible: Always Steps to Reproduce: 1. Right-click an entry in the mailbox folder 2. Select the properties action Actual Results: The action has been deactivated for the "account folder" as well as for "[Google Mail]", among other actions. Expected Results: It should be possible to set at least certain properties on those folders too, like the retrieval interval. After all the folders directly underneath (Inbox, "All Mail" etc) do have the option to use their parent folder's property for those settings. Because of that I'm marking this a major issue. I discovered this when I wanted to deactivate indexing for several folders at once, tired of having to wait for a folder sync each time I want to change that folder's properties. I'd deactivate email indexing altogether as used to be possible in the nepomuk days, but apparently we no longer have that choice... -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340614] assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614 --- Comment #12 from RJVB --- I'm not really familiar with IMAP UIDs, but what I gather from the original commit message is that they're not necessarily related to the actual number of messages in a folder. Indeed, it's quite suspicious that the error didn't show every time, and that merits someone having a look to understand why, IMHO (I just don't have the resources right now myself). The only logical explanation I see is that somehow the endpoint didn't get set in cases where the assert didn't fail. That could have been by design, but then the question becomes why I got the abort on something that's not supposed to be an exchange server! -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kontact] [Bug 340624] New: kontact won't exit and then crashes
https://bugs.kde.org/show_bug.cgi?id=340624 Bug ID: 340624 Summary: kontact won't exit and then crashes Product: kontact Version: unspecified Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Application: kontact (4.14.2) KDE Platform Version: 4.14.2 (Compiled from sources) Qt Version: 4.8.6 Operating System: Linux 3.13.11.6-ck1-kubuntu-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.1 LTS -- Information about the crash: - What I was doing when the application crashed: Kontact had yet again frozen in the "Retrieving Folder Contents" display, despite having just restarted akonadi TWICE. I used the Quit menu to exit it, and then noticed it didn't (running it via --nofork so it was apparent on the calling terminal). When I right-clicked the systray icon that was another indicator of kontact still running, the crash dialog appeared. All kdepim packages and akonadi are very recent git clones and are built from source via ppa:rjvbertin/kdepim -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". To enable execution of this file add add-auto-load-safe-path /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20-gdb.py line to your configuration file "/home/bertin/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/bertin/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Current thread is 1 (Thread 0x7f9ffdcab800 (LWP 16665))] Thread 4 (Thread 0x7f9fde53d700 (LWP 16668)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f9ff88da81d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f9ff88da859 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f9ff4fbc182 in start_thread (arg=0x7f9fde53d700) at pthread_create.c:312 #4 0x7f9ffaf1afbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7f9f9dc22700 (LWP 16670)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f9ff861b20d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f9ff8909fd6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f9ff4fbc182 in start_thread (arg=0x7f9f9dc22700) at pthread_create.c:312 #4 0x7f9ffaf1afbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f9f8e343700 (LWP 16683)): #0 0x7f9ffaf0dc6d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f9ff4adcfe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f9ff4add0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f9ffb8d272e in QEventDispatcherGlib::processEvents (this=0x7f9f880008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #4 0x7f9ffb8a05af in QEventLoop::processEvents (this=this@entry=0x7f9f8e342de0, flags=...) at kernel/qeventloop.cpp:149 #5 0x7f9ffb8a08ed in QEventLoop::exec (this=this@entry=0x7f9f8e342de0, flags=...) at kernel/qeventloop.cpp:204 #6 0x7f9ffb783413 in QThread::exec (this=) at thread/qthread.cpp:538 #7 0x7f9ffb785e03 in QThreadPrivate::start (arg=0xbde040) at thread/qthread_unix.cpp:349 #8 0x7f9ff4fbc182 in start_thread (arg=0x7f9f8e343700) at pthread_create.c:312 #9 0x7f9ffaf1afbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f9ffdcab800 (LWP 16665)): [KCrash Handler] #6 0x7f9f95149ae4 in MailCommon::FolderTreeWidget::folderTreeView (this=, this=) at ../../mailcommon/folder/foldertreewidget.cpp:261 #7 0x7f9f955043df in folderTreeView (this=, this=) at ../../kmail/kmmainwidget.h:146 #8 KMKernel::treeviewModelSelection (this=) at ../../kmail/kmkernel.cpp:1939 #9 0x7f9f954efa8e in KMail::KMSystemTray::slotContextMenuAboutToShow (this=0x1675610) at ../../kmail/kmsystemtray.cpp:307 #10 0x7f9ffb8b795a in QMetaObject::activate (sender=0x178f060, m=, local_signal_index=, argv=0x0) at kernel/qobject.cpp:3567 #11 0x7f9ffb8aab17 in QMetaMethod::invoke (this=this@entry=0x7fff49f44340, object=object@entry=0x178f060, connectionType=Qt::DirectConnection, connectionType@entry=Qt::AutoConnection, returnValue=..., val0=..., val1=..., val2=..., val3=..., val4=..., val5=..., val6=..., val7=..., val8=..., val9=...) at kernel/qmetaobject.cpp:1664 #12 0x7f9ffb8ad256 in QMetaObject::invokeMethod (obj=0x178f060, membe
[Akonadi] [Bug 340614] assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614 --- Comment #10 from RJVB --- PS: wouldn't it be of interest to know why this issue was triggered on a GMail imap account, which AFAIK no longer provides Exchange features? -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340614] assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614 --- Comment #9 from RJVB --- Yes, I was beaten to it (or would have been if this were a race). In a RR I'd have pointed out that it isn't necessary to use a temp. variable, and that the 1st comment is a little off now, but the purpose is clear. Or so it is when you take the trouble of digging up the original commit message ... -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340614] assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614 --- Comment #6 from RJVB --- Seems I was right: https://git.reviewboard.kde.org/r/120967/ -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340614] assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614
--- Comment #5 from RJVB ---
(In reply to Allen Winter from comment #3)
> try reverting 94b64eebb6a88846b221aad810045fecb4173f79 in
> kdepim-runtime/resources/imap
>
> I can try that myself tomorrow, but I'm leaving for the day.
Anyway, I think that this is what that patch should have looked like (partly):
{{{
// Are we already done?
if (lastUidToSearch >= m_searchUidIntervall.end()) {
m_searchUidIntervall = KIMAP::ImapInterval();
}
else {
//Prepare next chunk
m_searchUidIntervall.setBegin(lastUidToSearch + 1);
}
}}}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340614] assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614 --- Comment #4 from RJVB --- What's the official way of doing such a revert? -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340614] assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614
RJVB changed:
What|Removed |Added
CC||dvra...@redhat.com
--- Comment #2 from RJVB ---
I don't even understand why the ASSERT is active, because I don't build in
debug mode ...
Anyway, directly upstream of the failing assert is this:
``` C++
//Prepare next chunk
m_searchUidIntervall.setBegin(lastUidToSearch + 1);
//Or are we already done?
if (m_searchUidIntervall.begin() > m_searchUidIntervall.end()) {
```
where m_searchUidIntervall (with double l???) is the ImapInterval class where
things go wrong.
I think that the "or are we already done" test can never be true (the condition
wouldn't pass the assert and ::end returns 0x if no end has been
defined). But if it should be possible, then the assert is wrong.
However, ImapInterval::setBegin is unchanged from kdepimlibs 4.13.3 so I'm at a
loss.
As a side note: 0x is NOT the maximum value an ImapInterval::Id
(qint64) can reach ... (and for a signed int 0x7FF should have been used)
!!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340614] New: assertion failure in KIMAP::ImapInterval::setBegin
https://bugs.kde.org/show_bug.cgi?id=340614 Bug ID: 340614 Summary: assertion failure in KIMAP::ImapInterval::setBegin Product: Akonadi Version: unspecified Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: rjvber...@gmail.com CC: kdepim-bugs@kde.org, vkra...@kde.org Application: akonadi_imap_resource (4.14) KDE Platform Version: 4.14.2 (Compiled from sources) Qt Version: 4.8.6 Operating System: Linux 3.16.4-ck2-kubuntu-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.1 LTS -- Information about the crash: - What I was doing when the application crashed: I had launched kontact for the 1st time after building and installing it from ppa:rjvbertin/kdepim, a PPA holding current-as-of-today git/4.14 builds of kdepimlibs, kdepim and kdepim-runtime, built with clang-3.5 and full optimisation (as far as the CMake build system allows that). NB: only akonadi and the aforementioned packages are built from source. -- Backtrace: Application: RJVB@gmail of type IMAP E-Mail Server (akonadi_imap_resource), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". To enable execution of this file add add-auto-load-safe-path /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20-gdb.py line to your configuration file "/home/bertin/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/bertin/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Current thread is 1 (Thread 0x7f866233f7c0 (LWP 12771))] Thread 3 (Thread 0x7f864e081700 (LWP 12825)): #0 0x7f865db62c6d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f865cae5fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f865cae60ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f866194c72e in QEventDispatcherGlib::processEvents (this=0x7f86480008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #4 0x7f866191a5af in QEventLoop::processEvents (this=this@entry=0x7f864e080e20, flags=...) at kernel/qeventloop.cpp:149 #5 0x7f866191a8ed in QEventLoop::exec (this=this@entry=0x7f864e080e20, flags=...) at kernel/qeventloop.cpp:204 #6 0x7f86617fd413 in QThread::exec (this=) at thread/qthread.cpp:538 #7 0x7f86617ffe03 in QThreadPrivate::start (arg=0x1315940) at thread/qthread_unix.cpp:349 #8 0x7f865d1ca182 in start_thread (arg=0x7f864e081700) at pthread_create.c:312 #9 0x7f865db6ffbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f8647645700 (LWP 12842)): #0 0x7fffb97e9ff0 in clock_gettime () #1 0x7f865db7e46d in __GI___clock_gettime (clock_id=, tp=) at ../sysdeps/unix/clock_gettime.c:115 #2 0x7f866185ee4f in do_gettime (frac=0x7f8647644b80, sec=0x7f8647644b70) at tools/qelapsedtimer_unix.cpp:127 #3 qt_gettime () at tools/qelapsedtimer_unix.cpp:144 #4 0x7f866194e115 in updateCurrentTime (this=0x7f863c002d30) at kernel/qeventdispatcher_unix.cpp:354 #5 QTimerInfoList::timerWait (this=0x7f863c002d30, tm=...) at kernel/qeventdispatcher_unix.cpp:460 #6 0x7f866194c5b4 in timerSourcePrepareHelper (src=, timeout=0x7f8647644c54) at kernel/qeventdispatcher_glib.cpp:143 #7 0x7f866194c68d in timerSourcePrepare (source=, timeout=) at kernel/qeventdispatcher_glib.cpp:176 #8 0x7f865cae568d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x7f865cae5f03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x7f865cae60ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7f866194c72e in QEventDispatcherGlib::processEvents (this=0x7f863c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #12 0x7f866191a5af in QEventLoop::processEvents (this=this@entry=0x7f8647644e20, flags=...) at kernel/qeventloop.cpp:149 #13 0x7f866191a8ed in QEventLoop::exec (this=this@entry=0x7f8647644e20, flags=...) at kernel/qeventloop.cpp:204 #14 0x7f86617fd413 in QThread::exec (this=) at thread/qthread.cpp:538 #15 0x7f86617ffe03 in QThreadPrivate::start (arg=0x12a53a0) at thread/qthread_unix.cpp:349 #16 0x7f865d1ca182 in start_thread (arg=0x7f8647645700) at pthread_create.c:312 #17 0x7f865db6ffbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f866233f7c0 (LWP 12771)): [KCrash Handler] #6 0x7f865daabbb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #7 0x7f865daaefc8 in __GI_abort () at abort.c:89 #8 0x7f
[kontact] [Bug 340592] New: kontact crash on wake-from-suspend
https://bugs.kde.org/show_bug.cgi?id=340592 Bug ID: 340592 Summary: kontact crash on wake-from-suspend Product: kontact Version: unspecified Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Application: kontact (4.14.2) KDE Platform Version: 4.14.2 Qt Version: 4.8.6 Operating System: Linux 3.13.11.6-ck1-kubuntu-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04.1 LTS -- Information about the crash: - What I was doing when the application crashed: I had suspended my laptop in the evening by closing the lid (without verifying whatever it was doing). After waking it, I was greeted by kwallet asking me my password (undoubtedly at some akonadi resource's request) and the crash reporter window directly behind it. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". To enable execution of this file add add-auto-load-safe-path /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20-gdb.py line to your configuration file "/home/bertin/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/bertin/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Current thread is 1 (Thread 0x7f54bbef0800 (LWP 4525))] Thread 4 (Thread 0x7f549c8fe700 (LWP 4526)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f54b6bbb81d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f54b6bbb859 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f54b32bf182 in start_thread (arg=0x7f549c8fe700) at pthread_create.c:312 #4 0x7f54b939afbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7f545bfdb700 (LWP 4527)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f54b68fc20d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f54b6beafd6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f54b32bf182 in start_thread (arg=0x7f545bfdb700) at pthread_create.c:312 #4 0x7f54b939afbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f544cd72700 (LWP 4534)): #0 0x7fffb610c970 in clock_gettime () #1 0x7f54b93a946d in __GI___clock_gettime (clock_id=, tp=) at ../sysdeps/unix/clock_gettime.c:115 #2 0x7f54b9a46e4f in do_gettime (frac=0x7f544cd71b40, sec=0x7f544cd71b30) at tools/qelapsedtimer_unix.cpp:127 #3 qt_gettime () at tools/qelapsedtimer_unix.cpp:144 #4 0x7f54b9b36115 in updateCurrentTime (this=0x7f5448003130) at kernel/qeventdispatcher_unix.cpp:354 #5 QTimerInfoList::timerWait (this=0x7f5448003130, tm=...) at kernel/qeventdispatcher_unix.cpp:460 #6 0x7f54b9b345b4 in timerSourcePrepareHelper (src=, timeout=0x7f544cd71c14) at kernel/qeventdispatcher_glib.cpp:143 #7 0x7f54b9b3468d in timerSourcePrepare (source=, timeout=) at kernel/qeventdispatcher_glib.cpp:176 #8 0x7f54b2ddf68d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x7f54b2ddff03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x7f54b2de00ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7f54b9b3472e in QEventDispatcherGlib::processEvents (this=0x7f54480008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #12 0x7f54b9b025af in QEventLoop::processEvents (this=this@entry=0x7f544cd71de0, flags=...) at kernel/qeventloop.cpp:149 #13 0x7f54b9b028ed in QEventLoop::exec (this=this@entry=0x7f544cd71de0, flags=...) at kernel/qeventloop.cpp:204 #14 0x7f54b99e5413 in QThread::exec (this=) at thread/qthread.cpp:538 #15 0x7f54b99e7e03 in QThreadPrivate::start (arg=0x175aef0) at thread/qthread_unix.cpp:349 #16 0x7f54b32bf182 in start_thread (arg=0x7f544cd72700) at pthread_create.c:312 #17 0x7f54b939afbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f54bbef0800 (LWP 4525)): [KCrash Handler] #6 QSharedDataPointer (o=..., this=0x7fffb60e9120) at /usr/include/qt4/QtCore/qshareddata.h:93 #7 assignEntityPrivate (one=..., other=...) at ../../akonadi/entity.cpp:49 #8 0x7f54b82b3b75 in Akonadi::Entity::Entity (this=0x7fffb60e9180, other=...) at ../../akonadi/entity.cpp:55 #9 0x7f54536ce00d in MailCommon::FolderCollection::collection (this=) at ../../mailcommon/folder/foldercollection.cpp:151 #10 0x7f5453a62728 in KMMainWidget::slotMe
[kontact] [Bug 340557] New: kontact crash when activating the "Configure Kontact" menu action
https://bugs.kde.org/show_bug.cgi?id=340557 Bug ID: 340557 Summary: kontact crash when activating the "Configure Kontact" menu action Product: kontact Version: unspecified Platform: Compiled Sources OS: OS X Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Application: kontact (4.13.3) KDE Platform Version: 4.14.2 (Compiled from sources) Qt Version: 4.8.6 Operating System: Darwin 10.8.0 x86_64 Distribution (Platform): MacPorts Packages -- Information about the crash: - What I was doing when the application crashed: I planned to open Kontact's configuration dialog to verify some settings. There isn't much more to say, really ... Prior to doing that, I had associated a note to an email in a gmail IMAP account. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault [KCrash Handler] #4 0x000105cdd380 in Akonadi::AttributeFactory::registerAttribute (this=0x109808130, attr=0x12822a120) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdepimlibs4/kdepimlibs4/work/kdepimlibs-4.13.3/akonadi/attributefactory.cpp:130 #5 0x0001264ae6cf in global constructors keyed to a () #6 0x7fff5fc0d500 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () #7 0x7fff5fc0bcec in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj () #8 0x7fff5fc0bc9d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj () #9 0x7fff5fc0bc9d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj () #10 0x7fff5fc0bda6 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE () #11 0x7fff5fc08fbb in __dyld_dlopen () #12 0x7fff85efee40 in dlopen () #13 0x000104e4437d in QLibraryPrivate::load_sys (this=0x1282297a0) at plugin/qlibrary_unix.cpp:226 #14 0x000104e3f309 in QLibraryPrivate::load (this=0x1282297a0) at plugin/qlibrary.cpp:469 #15 0x000104e3f41c in QLibrary::load (this=) at plugin/qlibrary.cpp:910 #16 0x000104975da7 in KLibLoader::library (this=, _name=, hint=@0x7fff5fbfbc90) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kdecore/util/klibloader.cpp:105 #17 0x000106ca2475 in KLibLoader::createInstance (libname=, parent=0x128227ca0, args=@0x128228c60, error=0x7fff5fbfbdc4) at klibloader.h:264 #18 0x000106ca2406 in KService::createInstance (service=, parent=0x128227ca0, args=@0x128228c60, error=0x7fff5fbfbdc4) at kservice.h:616 #19 0x000106ca1738 in KCModuleLoader::loadModule (mod=@0x128228c90, report=KCModuleLoader::Inline, parent=0x128227ca0, args=@0x128228c60) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kutils/kcmoduleloader.cpp:96 #20 0x000106ca7ae0 in KCModuleProxyPrivate::loadModule (this=0x128228c60) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kutils/kcmoduleproxy.cpp:107 #21 0x000106ca7652 in KCModuleProxy::realModule (this=) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kutils/kcmoduleproxy.cpp:83 #22 0x000106ca8d61 in KCModuleProxy::useRootOnlyMessage (this=0x128227ca0) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kutils/kcmoduleproxy.cpp:316 #23 0x000106ca521d in KCMultiDialog::addModule (this=0x127d55d20, moduleInfo=@0x10aaa93e0, parentItem=0x127cb0ae0, args=) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kutils/kcmultidialog.cpp:390 #24 0x000106cb986f in KSettings::DialogPrivate::createDialogFromServices (this=0x127d25810) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kutils/ksettings/dialog.cpp:358 #25 0x000106cb8612 in KSettings::Dialog::showEvent (this=0x127d55d20) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kutils/ksettings/dialog.cpp:127 #26 0x0001038e115a in QWidget::event (this=0x127d55d20, event=0x7fff5fbfce00) at kernel/qwidget.cpp:8607 #27 0x0001038860fd in QApplicationPrivate::notify_helper (this=0x10aa10dc0, receiver=0x127d55d20, e=0x7fff5fbfce00) at kernel/qapplication.cpp:4565 #28 0x00010388ca78 in QApplication::notify (this=0x7fff5fbfe588, receiver=0x127d55d20, e=0x7fff5fbfce00) at kernel/qapplication.cpp:4426 #29 0x00010325c3a7 in KApplication::notify (this=0x7fff5fbfe588, receiver=0x127d55d20, event=0x7fff5fbfce00)
[kontact] [Bug 340344] New: Akonadi crash while trying to quit it (after "gmail too many simult. connections" and catatonic "Retrieving Folder Contents"
https://bugs.kde.org/show_bug.cgi?id=340344 Bug ID: 340344 Summary: Akonadi crash while trying to quit it (after "gmail too many simult. connections" and catatonic "Retrieving Folder Contents" Product: kontact Version: unspecified Platform: Compiled Sources OS: OS X Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Application: kontact (4.13.3) KDE Platform Version: 4.14.2 (Compiled from sources) Qt Version: 4.8.6 Operating System: Darwin 10.8.0 x86_64 Distribution (Platform): MacPorts Packages -- Information about the crash: - Unusual behaviour I noticed: Kontact had gone into its catatonic "Retrieving Folder Contents" state once more, possibly induced this time by a "Gmail too many simultaneous connections" issue which I had overlooked because the window had been opened somewhere behind all other windows. - What I was doing when the application crashed: I was trying to get Kontact to quit. As often happens on OS X (but which may correspond to a stray kontact process hanging around on Linux, killable only through `killall -1 kontact`), the process didn't quit completely after I triggered the Quit menu. Instead, it hung around windowless, with just the Application menu in the global menubar to give it another Quit command. I think I gave 2, and then kontact crashed. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault [KCrash Handler] #4 0x0001202740c8 in KMMainWidget::itemsFetchDone (this=0x11c5c3820, job=) at qwidget.h:497 #5 0x000120344cd6 in KMMainWidget::qt_static_metacall (_o=, _c=, _id=, _a=0x7fff5fbf9a90) at moc_kmmainwidget.cpp:539 #6 0x000104e6c2fe in QMetaObject::activate (sender=0x1263f8d70, m=, local_signal_index=, argv=) at kernel/qobject.cpp:3622 #7 0x00010485415c in KJob::isAutoDelete () at /Volumes/Debian/Users/bertin/work/src/new/KDE/kdelibs/kdelibs4-4.14.0/kdecore/jobs/kjob.h:207 #8 0x00010485415c in KJob::emitResult (this=0x1263f8d70) at kjob.moc:320 #9 0x000105db35f3 in ~QString [inlined] () at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdepimlibs4/kdepimlibs4/work/kdepimlibs-4.13.3/akonadi/job.cpp:64 #10 ~QString [inlined] () at /Volumes/Debian/MP6/Library/Frameworks/QtCore.framework/Versions/4/Headers/qstring.h:880 #11 0x000105db35f3 in Akonadi::JobPrivate::handleResponse (this=, tag=, data=@0x7fff5fbf9cf0) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdepimlibs4/kdepimlibs4/work/kdepimlibs-4.13.3/akonadi/job.cpp:65 #12 0x000105e0512d in ~QByteArray [inlined] () at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdepimlibs4/kdepimlibs4/work/kdepimlibs-4.13.3/akonadi/session.cpp:236 #13 ~QByteArray [inlined] () at /Volumes/Debian/MP6/Library/Frameworks/QtCore.framework/Versions/4/Headers/qbytearray.h:401 #14 0x000105e0512d in Akonadi::SessionPrivate::dataReceived (this=0x1219f2cb0) at qbytearray.h:236 #15 0x000104e6c2fe in QMetaObject::activate (sender=0x11efc12a0, m=, local_signal_index=, argv=) at kernel/qobject.cpp:3622 #16 0x000104e6c2fe in QMetaObject::activate (sender=0x11efc25f8, m=, local_signal_index=, argv=) at kernel/qobject.cpp:3622 #17 0x000102c7fb71 in ~QScopedValueRollback [inlined] () at socket/qabstractsocket.cpp:654 #18 0x000102c7fb71 in ~QScopedValueRollback [inlined] () at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.6/src/corelib/tools/qscopedvaluerollback.h:63 #19 0x000102c7fb71 in QAbstractSocketPrivate::canReadNotification (this=0x11ef5ee70) at socket/qabstractsocket.cpp:654 #20 0x000102c8a749 in QReadNotifier::event (this=, e=) at socket/qnativesocketengine.cpp:1151 #21 0x0001038830fd in QApplicationPrivate::notify_helper (this=0x1089136f0, receiver=0x124778bd0, e=0x7fff5fbfa6b0) at kernel/qapplication.cpp:4565 #22 0x00010388a17e in QApplication::notify (this=0x7fff5fbfe588, receiver=, e=0x7fff5fbfa6b0) at kernel/qapplication.cpp:3947 #23 0x00010325b827 in KApplication::notify (this=0x7fff5fbfe588, receiver=0x124778bd0, event=0x7fff5fbfa6b0) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.2/kdeui/kernel/kapplication.cpp:321 #24 0x000104e52fac in QCoreApplication::notifyInternal (this=0x7fff5fbfe588, receiver=0x124778bd0, event=0x7fff5fbfa6b0) at kernel/qcoreapplication.cpp:953 #25 0x00010383be54 in qt_mac_socket_callback () #26 0x7fff80461bba in __CFSocketDoCallback () #27 0x7fff804615bb in __CFSocketPerformV0 () #28 0x7fff804393d1 in __CFRunLoopDoSources0 () #29 0x7fff804375c9 in __CFRunLo
[kmail2] [Bug 299224] kontact crash on quit
https://bugs.kde.org/show_bug.cgi?id=299224 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 299224] kontact crash on quit
https://bugs.kde.org/show_bug.cgi?id=299224 --- Comment #9 from RJVB --- Created attachment 89309 --> https://bugs.kde.org/attachment.cgi?id=89309&action=edit New crash information added by DrKonqi kontact (4.13.3) on KDE Platform 4.14.2 using Qt 4.8.6 - What I was doing when the application crashed: I quit Kontact through the relevant menu item, in hope of getting rid of the "Retrieving folder content" catatonic state - Unusual behaviour I noticed: After waking my computer from sleep, mail was being checked for normally and Kontact showed the progress normally. The message view pane remained frozen on "Retrieving folder contents" however, and I don't think new mail actually showed up in the message list. -- Backtrace (Reduced): #5 0x000103dce3c7 in QItemSelectionModel::selectedIndexes (this=0xc000121a5) at itemviews/qitemselectionmodel.cpp:1432 #6 0x0001206b498e in MailCommon::FolderTreeWidget::selectedCollections (this=) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdepim4/kdepim4/work/kdepim-4.13.3/mailcommon/folder/foldertreewidget.cpp:244 #7 0x00012035d670 in KMMainWidget::updateFolderMenu (this=0x121a38b70) at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdepim4/kdepim4/work/kdepim-4.13.3/kmail/kmmainwidget.cpp:4115 #8 0x00012043fbf2 in KMMainWidget::qt_static_metacall (_o=, _c=, _id=, _a=) at moc_kmmainwidget.cpp:525 [...] #10 0x000104e67280 in QObject::event (this=0x121a38dc8, e=) at kernel/qobject.cpp:1184 -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340046] after long inactivity (sleep) mailfilter agent remains at 0% indefinitely (and kmail at "Retrieving folder contents")
https://bugs.kde.org/show_bug.cgi?id=340046 --- Comment #1 from RJVB --- Created attachment 89172 --> https://bugs.kde.org/attachment.cgi?id=89172&action=edit output recorded after akonadictl restart (2x) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 340046] New: after long inactivity (sleep) mailfilter agent remains at 0% indefinitely (and kmail at "Retrieving folder contents")
https://bugs.kde.org/show_bug.cgi?id=340046 Bug ID: 340046 Summary: after long inactivity (sleep) mailfilter agent remains at 0% indefinitely (and kmail at "Retrieving folder contents") Product: Akonadi Version: 1.12.91 Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Mail Filter Agent Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Since upgrading to 4.14.1 and now 4.14.2 from the Kubuntu 14.04 backports PPA I experience a very annoying issue with kmail/kontact each time I wake the computer from sleep. New mail appears to be fetched normally, but Kontact remains stuck at "Retrieving folder contents" when I select messages or change folders or even (imap) accounts. Switching it off/online does not unblock the situation, I need to restart akonadi. After the 1st `akonadictl restart`, the situation appears to be unblocked, but the mail filter agent remains at 0% indefinitely according to both kontact's progress widget and akonadiconsole. A second akonadictl restart is required within a short laps of time in order to return things to normal. Then one can see the mail filter resource do some actual work at some point of the synchronisation process. Given that this is on a netbook, we are by now long minutes from the moment I woke the computer from sleep. kontact/kmail usually get in the same "Retrieving folder contents" catatonic state after having been kept offline for a while. Under 4.13.3 this was my most reliable way of preventing the "gmail too many simultaneous connections" bug by having only 1 kontact process online on 1 computer at a time. Reproducible: Always Steps to Reproduce: 1. Wake computer from sleep in the morning 2. Ensure it connects to the correct WLAN and enter the wallet password in the dialog posted at kontact/akonadi's request 3. Wait for sync to complete, try to read new (or even old email) Actual Results: 4. when it's clear kontact won't display anything else but "Retrieving folder contents", 5. do akonadictl restart 6. admire the dance in the expanded kontact progress widget and notice how the mail filter agent appears there 7. remark that said filter agent is going to remain stuck at 0% again (long) after everything else settles down (and you can actually read email) 8. do another akonadictl restart 9. as in 6, but this time the filter agent actually does things and completes its job Expected Results: to be able to start handling email normally after a wake from sleep or lengthy period of having kept kontact/kmail offline. I'm attaching a log of output obtained after entering akonadictl restart in a terminal, with debug output activated for the mail filter agent. It starts with the last output from the server processes being stopped (which look suspicious) and then shows the trace of new processes being started. It includes the output from the 2nd `akonadictl restart` required to return to normal functioning, and from what I can see it is only after that restart that output from the mail filter agent appears in the log. It turns out that mailfilter has the same "no progress" issue when akonadi is restarted after functioning normally for a while. A very similar issue plagues my "kdepim user experience" under OS X with kdepim 4.13.3 and akonadi 1.13.0 and (of course) a mostly identical configuration (accounts, kontact settings). Possibly related observation: regularly email deleted from my main gmail imap account is moved not to the configured trash (on the gmail server) but to my local mail trash. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kdepim] [Bug 340034] font settings not respected in LocalMail/MBox settings dialog
https://bugs.kde.org/show_bug.cgi?id=340034 --- Comment #1 from RJVB --- Created attachment 89167 --> https://bugs.kde.org/attachment.cgi?id=89167&action=edit Screenshot showing the font settings in systemsettings/app appearance/Fonts as well as the typeface errors in qtconfig and the localMail-of-type-MBox configuration dialog Screenshot showing the font settings in systemsettings/app appearance/Fonts as well as the typeface errors in qtconfig and the localMail-of-type-MBox configuration dialog -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kdepim] [Bug 340034] New: font settings not respected in LocalMail/MBox settings dialog
https://bugs.kde.org/show_bug.cgi?id=340034 Bug ID: 340034 Summary: font settings not respected in LocalMail/MBox settings dialog Product: kdepim Version: unspecified Platform: MacPorts Packages OS: OS X Status: UNCONFIRMED Severity: normal Priority: NOR Component: wizards Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com The settings dialog for the "localMail of type MBox" account type doesn't respect the KDE font settings Reproducible: Always Steps to Reproduce: 1. configure fonts, e.g. Novarese Bk Bt Medium 11 pt as the general font 2. open the settings of a (newly added or not) "LocalMail of type MBox" account in kmail or kontact Actual Results: The majority of the text shown in the dialog (QLabels?) is set in what looks like Lucida Grande 13pt, which happens to be the default font on OS X. Expected Results: The dialog should be set in my general font (or any of the other fonts configured via System Settings). This is most likely a Qt error, but it's the first time I see it in a KDE app. See the screenshot: Qt4 is set to use the same font as KDE but even the QtConfig settings dialog doesn't respect that setting. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 339006] New: message list fonts: use bold/italic/etc as attributes rather than as font instances
https://bugs.kde.org/show_bug.cgi?id=339006
Bug ID: 339006
Summary: message list fonts: use bold/italic/etc as attributes
rather than as font instances
Product: kmail2
Version: unspecified
Platform: Other
OS: All
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: UI
Assignee: kdepim-bugs@kde.org
Reporter: rjvber...@gmail.com
The font settings dialog presents a list of fonts and a list of attributes for
the selected font. Selecting a font with a given attribute will however be
remembered as a reference to the font file. This is fine except in a UI where
you're configuring attributes of elements, and not purely elements.
For example, "new/unread", "important" and "action item" are not independent UI
elements, they're message attributes.
Reproducible: Always
Steps to Reproduce:
Select a font for the message list, and then apply to following font
attributes:
1. unread messages in Bold
2. important messages in Italic
3. action item messages in Italic
Actual Results:
Important, unread messages are displayed in Italic
Unread action items are displayed in Bold
Expected Results:
Both important and action items that are unread should be displayed in Bold
Italic
I know that the underlying code will at some point have to work with a
reference to a font file that represents the font with the selected attributes.
I also realise that semantically speaking the font selection dialog presents
settings for elements that are either new or important or action items. It
would just be nice if the particular font file could be selected not at the
moment the user picks the font+attributes for a given UI element. Or, when
underneath the font selection dialog the implementation takes the various
combinations of element attributes into account.
(I.e. internally cache font references for the 8 various possible combinations
of {r,unread}{i,important}{a,action item})
NB: remembering choises as font+attribute(s)+size may actually address a
related, global issue on OS X where e.g. the SemiBold attribute tends to get
"promoted" to Bold (or even Negrita or Black). A font like Segoe UI is a prime
example of this: picking a SemiBold version of this font for UI elements
usually becomes the Negrita (Black) version. I'm not sure if this is an actual
bug nor where/how to report it so mention it here.
--
You are receiving this mail because:
You are the assignee for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 338936] New: issues with new email notifications on OS X
https://bugs.kde.org/show_bug.cgi?id=338936 Bug ID: 338936 Summary: issues with new email notifications on OS X Product: kmail2 Version: 4.12.5 Platform: MacPorts Packages OS: OS X Status: UNCONFIRMED Severity: normal Priority: NOR Component: UI Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com I am running into 2 issues with new email notifications on OS X. For now I'm reporting them here together, if either one should be reported against another KDE component I'll be happy to create a new ticket. In short: 1) message popup notifications steal focus on OS X, and don't return it. 2) I cannot seem to deactivate the popup messages. This one is actually new since yesterday - but I haven't code nor settings files. Reproducible: Always Steps to Reproduce: 1. Start kmail 2. Bring some other application to the foreground, interact with it 3. When new mail arrives, a message pops up, grabbing the focus and not returning it. 4. Check if you want pop up notifications in the 1st place Actual Results: Pop up messages grab focus and don't return it to whomever it had. According to the notifications settings, they shouldn't appear in the 1st place. Expected Results: 1. Pop up messages don't grab focus and even if they did, they'd return it to the previous owner. 2. Pop up messages appear only for events for which they have been configured. Re. 1) in the expected results: OS X provides the means for this. The resulting messages might be less "rich" as pure KDE ones (no theming for starters) but at least they "behave" OS X is going to be restricted to running KDE 4 applications for a while longer, and MacPorts is only now preparing the move to 4.13 . Hence the report against "such an old" kmail version. I'd be happy to have a look at how these popup messages could be improved on OS X (possibly even "backporting" the approach used in KF5, if relevant) but I'd need some pointers about where and for what to look, etc. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 338370] Kmail2 (4.14rc) with gmail too many simultaneous imap connections
https://bugs.kde.org/show_bug.cgi?id=338370 --- Comment #5 from RJVB --- > Note that IDLE only works on the INBOX folder: it won't update your other > folders, if GMail automatically files an email there (due to filters for > instance). I saw work somewhere online that would add IDLE support for other folders, but it's possible that'd be at the cost of 1 connection per folder ... > For performance reasons the IMAP resource keeps the connections open as long > as possible, so it should not matter whether you enable/disable interval > check. I have a hunch that performance is more hampered by the fact that messages are downloaded systematically even when right-clicked to be deleted or when part of a multiple selection (I am not downloading offline copies) than by reconnecting to the server. Provided each reconnect isn't going to present a wallet unlock request, of course. Would it be a thought to close the connections if the server replies with the (unambiguous) error message? -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 338370] Kmail2 (4.14rc) with gmail too many simultaneous imap connections
https://bugs.kde.org/show_bug.cgi?id=338370 --- Comment #3 from RJVB --- Some feedback: I am currently testing a configuration without explicit, timed check for new mail in my gmail inbox, relying instead on the IDLE feature for being notified about incoming mail in that mailbox (since the IDLE feature cannot be deactivated anyway). Since configuring things that way, I have had no more errors about too many simultaneous connections on that account. I do get kwallet unlock request for reading the credentials to the account from time to time (the wallet is set to close after 2min). (Personally I'd store an encrypted copy of the password in RAM to prevent that, but that's a different issue.) Note that this is after downgrading to KDE 4.13.3, which reduced but did not eliminate the simult. connections lock-out issue. Curiously, I also no longer get a dialog for entering the actual gmail password anew. I used to get that after the kwallet dialog had gone undetected for too long (?), as if there's a timeout on the request. I haven't had time to confirm, but it seems that this (always?) preceded the lock-out issue. I think I still observed that behaviour in KDE 4.13.3, so after downgrading but before removing the timed poll from the gmail inbox. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 338370] Kmail2 (4.14rc) with gmail too many simultaneous imap connections
https://bugs.kde.org/show_bug.cgi?id=338370 --- Comment #2 from RJVB --- Something else: given how gmail and kmail/akonadi all support IMAP IDLE, is it still necessary to poll explicitly at regular intervals - and would NOT doing so improve things? Googling for akonadi imap IdleRidPath gave multiple hits for multiple IDLE paths (which I guess I'd need) but also mentions a GUI for configuring those ... and I don't seem to have that. Has that feature ever been implemented and committed? -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 338370] Kmail2 (4.14rc) with gmail too many simultaneous imap connections
https://bugs.kde.org/show_bug.cgi?id=338370 --- Comment #1 from RJVB --- I downgraded to KDE 4.13.3, and removed,recreated the gmail account. The issue has become much less frequent. Here's some output from netstat: With the "too many simultaneous connections, enterpassword/try again/cancel" alert still open: > netstat -aeepW | fgrep imap (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp0 0 patux:57979 wi-in-f109.1e100.net:imaps ESTABLISHED bertin 5617520 18352/akonadi_imap_ tcp0 0 patux:57526 wi-in-f109.1e100.net:imaps ESTABLISHED bertin 5394945 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392495 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392357 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392742 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392270 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392192 18352/akonadi_imap_ After hitting cancel, causing kmail to take the account offline: netstat -aeepW | fgrep imap (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp0 0 patux:57526 wi-in-f109.1e100.net:imaps TIME_WAIT root 0 - unix 3 [ ] STREAM CONNECTED 5392495 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392357 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392742 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392270 18352/akonadi_imap_ unix 3 [ ] STREAM CONNECTED 5392192 18352/akonadi_imap_ In other words, taking the account offline does not cause it to close all its connections to the server, something I'd expect. Sending a SIGHUP to 18352 causes it to exit, and immediately thereafter I can online the account in kmail with success.That would appear to offer at least a suggestion for a workaround solution. The restart command in the akonadiconsole does NOT have that effect (in fact, it rarely appears to do anything with imap accounts ... unless they're working properly?!) but it'd be much more convenient NOT to have to launch a separate application to correct an issue that's apparent in kmail. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 338370] Kmail2 (4.14rc) with gmail too many simultaneous imap connections
https://bugs.kde.org/show_bug.cgi?id=338370 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 338370] New: Kmail2 (4.14rc) with gmail too many simultaneous imap connections
https://bugs.kde.org/show_bug.cgi?id=338370 Bug ID: 338370 Summary: Kmail2 (4.14rc) with gmail too many simultaneous imap connections Product: kmail2 Version: unspecified Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com With the latest (4.13.97) packages in the Kubuntu 14.04 backport PPA, kmail2 has become (almost) unusable with my main gmail account. I've always had the occasional failure due to gmail's limit on the number of imap connections (though I *think* it started with 4.13) but now this has become a serious blocker. There is some voodoo involving various combinations of offlining the account and restarting the akonadi server and/or kmail, but it never takes long before I get bitten again. I do not only have my Linux workstation on which I handle email, but also an Android tablet, an iPhone and a Mac workstation, so the gmail account has a number of filters that sorts incoming mail in folders on the server. Because of that and gmail's 15 connection limit, it is extremely important that each client behaves and doesn't just multiply the number of concurrent connections (for scanning all those folders in parallel, for instance) without ever closing them immediately when done. Thunderbird has the same issue with its default of 5 simultaneous connections max. per server, but it allows to dial that value down. With 1, I can avoid the issue. I have thus gone back to using Thunderbird and removed all my kmail/akonadi imap accounts (since they cannot be deactivated permanently otherwise) in hope and waiting for better days. NB: the issue doesn't appear to occur (or MUCH less frequently) when just letting the akonadi resources run without kmail running. To me this suggests that it's something in the way kmail talks to the akonadi resources that triggers the issue. Is there a way to limit the number of simultaneous imap connections, either in kmail or in akonadi? -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 337744] Subscriptions should be configurable before the first sync
https://bugs.kde.org/show_bug.cgi?id=337744 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #1 from RJVB --- Second that. Here's a good example where the current subscription model is completely useless. I run an imap server on my main workstation; this is the most elegant and appropriate solution I found to be able to archive email from different locations (= computers). When one connects to the imap daemon, it's like connecting over any other file/folder based protocol: one starts in the home directory. So scanning for mailboxes means scanning each and every directory under my home directory, possibly even scanning through the 33GB worth of files that live there (more if imapd follows symlinks which I'm not sure du does). To put this in context: I have about 550MB of email in my archive folder, ~/Mail/Archive. I just tried this once again. The initial sync took about 15 minutes to grind to a halt, possibly because of memory issues (despite the 8GB of RAM and 10GB of swap). Of course this example also shows that the current subscription mechanism doesn't really allow to do anything before the 1st sync. After all, it appears to be geared to subscribe to individual mailboxes (i.e. mbox type files on the server). In my case the thing to do would be to subscribe to a *folder* on the server, probably by typing the path into a text field (or else the initial scan should not be exhaustively recursive but proceed level by manually selected level). This action would then subscribe all mailboxes contained in that folder (and ideally do this automatically for each new mailbox that might be created behind akonadi's back, for instance with Apple Mail on a different computer). What I'm describing is in fact what other email clients call "imap server directory" or "prefix path", a feature which I think is orthogonal to the subscription feature (and indeed often proposed in addition to subscriptions). -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 335795] IMAP namespace support is incomplete/insufficient on large imap accounts
https://bugs.kde.org/show_bug.cgi?id=335795 --- Comment #4 from RJVB --- Yes, there are 2 things which make (made) the current implementation unworkable for me. Most importantly, the fact that there is no way to obtain the list of folders (not) to subscribe to before the whole account is scanned. (And again, on a typical workstation also running an imapd that amounts to transferring all files under your account, possibly even trying to parse them.) The other thing is that there is nothing recursive to a subscription, i.e. there is no way I found to select all mailboxes in the directory where one keeps them. One could argue that that's a once-only action, but in reality that would go against the fact that IMAP has always been designed to allow access from multiple locations (i.e., mailboxes might be created or deleted while connecting from a different location). Isn't there a "closed - wontfix" status? -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 335795] IMAP namespace support is incomplete/insufficient on large imap accounts
https://bugs.kde.org/show_bug.cgi?id=335795 RJVB changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|UNCONFIRMED --- Comment #2 from RJVB --- Have you actually tried to use subscriptions in a use case like the one I described? Your claim about subscriptions is true only in theory, in practice one has to wait longer for a possibility to subscribe to only the desired mailboxes than it takes to decide to install another email client, install, configure and start using it. Much longer. So yeah, if speed and ease of use (= not having to subscribe to ALL folders inside/under the mailbox repository folder) aren't useful then I guess the majority of other readers that do provide a "prefix path" setting are just plain wrong to do so. No irony intended either (sarcasm and cynicism are a different matter) ... BTW, nothing has been resolved here, so I'm setting a more appropriate status. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 336162] New: kmail crashed when trying to open a message from the outbox
https://bugs.kde.org/show_bug.cgi?id=336162 Bug ID: 336162 Summary: kmail crashed when trying to open a message from the outbox Classification: Unclassified Product: kmail2 Version: 4.13 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com Application: kmail (4.13) KDE Platform Version: 4.13.0 Qt Version: 4.8.6 Operating System: Linux 3.13.11.2-ck1-kubuntu-amdf10-rjvb x86_64 Distribution: Ubuntu 14.04 LTS -- Information about the crash: - What I was doing when the application crashed: I had cancelled a password dialog because I noticed that a message written after clicking on a mailto: link in my browser didn't have the desired From: address. In order to change that I tried to open the message from the outbox. I got 1 or 2 errors about a missing .signature file, which I clicked away. I also probably double-clicked the message a 2nd time because of lack of progress feedback. -- Backtrace: 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 0x7f1014add800 (LWP 12373))] Thread 5 (Thread 0x7f0fec8f6700 (LWP 12377)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f10063d581d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f10063d5859 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f100f70c182 in start_thread (arg=0x7f0fec8f6700) at pthread_create.c:312 #4 0x7f1011e4b30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 4 (Thread 0x7f0fab764700 (LWP 12378)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f100611620d in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #2 0x7f1006404fd6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4 #3 0x7f100f70c182 in start_thread (arg=0x7f0fab764700) at pthread_create.c:312 #4 0x7f1011e4b30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7f0faa89c700 (LWP 12379)): #0 0x7f1011e3c6bd in read () at ../sysdeps/unix/syscall-template.S:81 #1 0x7f1009f0fc20 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f1009eceb14 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f1009ecef7b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f1009ecf0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f10127da7be in QEventDispatcherGlib::processEvents (this=0x7f0f9c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #6 0x7f10127ac0af in QEventLoop::processEvents (this=this@entry=0x7f0faa89bde0, flags=...) at kernel/qeventloop.cpp:149 #7 0x7f10127ac3a5 in QEventLoop::exec (this=this@entry=0x7f0faa89bde0, flags=...) at kernel/qeventloop.cpp:204 #8 0x7f10126a8c5f in QThread::exec (this=) at thread/qthread.cpp:537 #9 0x7f10126ab32f in QThreadPrivate::start (arg=0x251b000) at thread/qthread_unix.cpp:349 #10 0x7f100f70c182 in start_thread (arg=0x7f0faa89c700) at pthread_create.c:312 #11 0x7f1011e4b30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f0f98f9d700 (LWP 12626)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f0ffc3eeffb in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #2 0x7f0ffc3ef039 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #3 0x7f100f70c182 in start_thread (arg=0x7f0f98f9d700) at pthread_create.c:312 #4 0x7f1011e4b30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f1014add800 (LWP 12373)): [KCrash Handler] #6 QMutex::lock (this=this@entry=0x680073002f00ba) at thread/qmutex.cpp:150 #7 0x7f10127b1139 in QCoreApplication::postEvent (receiver=0x39de950, event=0x701e6e0, priority=0) at kernel/qcoreapplication.cpp:1358 #8 0x7f10127c187a in QMetaObject::activate (sender=sender@entry=0x39de950, m=m@entry=0x7f1013c173e0 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fffd5c9f570) at kernel/qobject.cpp:3539 #9 0x7f101397c95e in KMCommand::messagesTransfered (this=this@entry=0x39de950, _t1=_t1@entry=KMCommand::OK) at moc_kmcommands.cpp:116 #10 0x7f1013884f33 in KMCommand::slotJobFinished (this=0x39de950) at ../../kmail/kmcommands.cpp:367 #11 0x7f10127c187a in QMetaObject::activate (sender=sender@entry=0x5a7d840, m=m@entry=0x7f10142e9600 , local_signal_index=local_signal_index@entry=3, argv=argv@entry=0x7fffd5c9f710) at kernel/qobject.cpp:3539 #12 0x7f1013f59622
[Akonadi] [Bug 335795] New: IMAP namespace support is incomplete/insufficient on large imap accounts
https://bugs.kde.org/show_bug.cgi?id=335795 Bug ID: 335795 Summary: IMAP namespace support is incomplete/insufficient on large imap accounts Classification: Unclassified Product: Akonadi Version: 4.13 Platform: unspecified OS: All Status: UNCONFIRMED Severity: grave Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: rjvber...@gmail.com CC: kdepim-bugs@kde.org, vkra...@kde.org I run an imap server on my main workstation, allowing me to archive email no matter from what computer I'm doing that. Those archives live under ~/Mail/Archives, and an imap client not ignoring everything above that path will spend a very long time indexing ~ (I had to kill and delete the resource when it hogged the whole computer after I let it run for about 2h). I've skimmed through a few discussions on kmail's approach to the "imap prefix path" most email readers support, and while I tend to agree that if namespaces are the standards compliant way to do things they should be used, I also think the implementation isn't without flaws. Let's ignore the fact that the current imap configuration dialog doesn't even mention namespaces (presumably replaced by server-side subscriptions?). The real gripe I have is that I apparently have to let the imap process index the full server-side contents before I can point it to the appropriate root folder (Mail/Archives). And it's not just an omission in the GUI: I tried simulating the required actions with a small imap account, and observed that apparently all mailboxes (folders) under the root are listed explicitly in the configuration file, rather than only the root folder. Which in my book is not using a namespace as any addition (new folder) will have to be added manually to the selection (requiring another lengthy indexing step). I'd suggest reinstating a simple "prefix path" feature that can be specified (= typed in) even before the first connection to a new imap account. It's only a single text entry field, and internally it could perfectly well be translated into the appropriate namespace magic. Reproducible: Always Steps to Reproduce: 1. set up an imap server on a workstation 2. Use Thunderbird, Apple's Mail.app, sylpheed, pine, just about any MUA to set up an email archive on that imap server, connecting with your work/home account on that, for instance under Mail/Archives (= ~/Mail/Archives) 3. Define an akonadi imap resource pointing to that same IMAP server, using the same login credentials 4. Sit back and wait ... Actual Results: A synchronisation step will be triggered that can take hours to complete if the user home directory (the "~" namespace) contains a large amount of files and folders, of which only 1 is relevant for the imap resource (Mail/Archives, and the mbox files contained therein). Expected Results: Given additional configuration options, either to specify a path prefix or to alter the namespace queried, or both (as Thunderbird does). I don't have direct experience using imap namespaces, but if they don't allow to specify the path to where the mailboxes are (to be) stored, an additional mechanism should be implemented. Again, just about any other email client allows to do that. Following standards nice, but it should not become a case of form over function. I'm marking this bug as "grave", because it requires serious workarounds if one is obliged to work with an imap server as outlined above. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 334170] IMAP accounts are always switched online at startup
https://bugs.kde.org/show_bug.cgi?id=334170 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #1 from RJVB --- I concur, while it is a good idea to offline resources when quitting kmail, the very least would be to store and restore the state they had. That way, an account that was taken offline manually will remain so across restarts until it is onlined manually again. Note that this is how OS X's Mail.app works, and there too it is a setting that completes the account-specific settings whether and how often checks for new mail ought to be done. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 335354] New: imap email server crash upon wake-from-sleep
https://bugs.kde.org/show_bug.cgi?id=335354
Bug ID: 335354
Summary: imap email server crash upon wake-from-sleep
Classification: Unclassified
Product: Akonadi
Version: 4.13
Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: IMAP resource
Assignee: chrig...@fastmail.fm
Reporter: rjvber...@gmail.com
CC: kdepim-bugs@kde.org, vkra...@kde.org
Application: akonadi_imap_resource (4.13)
KDE Platform Version: 4.13.0
Qt Version: 4.8.6
Operating System: Linux 3.13.9-ck1-kubuntu-ck-amdf10-rjvb x86_64
Distribution: Ubuntu 14.04 LTS
-- Information about the crash:
- What I was doing when the application crashed:
Waking the computer from sleep ("suspend to ram", initiated by closing the
laptop screen/cover).
- Unusual behaviour I noticed:
The computer is set to lock the screen before being suspended. When waking the
system, I just had the time to notice some output to the console before the
screenlocker kicked in and presented the password dialog. I cannot be certain,
but I think the output was from the brcmsmac driver which I started using
recently because the Broadcom STA driver (wl.ko) doesn't work well with my
access points.
-- Backtrace:
Application: RJVB@MW of type IMAP E-Mail Server (akonadi_imap_resource),
signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f58a78977c0 (LWP 2520))]
Thread 4 (Thread 0x7f58908fd700 (LWP 2746)):
#0 0x7f58a2665569 in __GI___pthread_mutex_lock (mutex=0x7f5888007c10) at
../nptl/pthread_mutex_lock.c:125
#1 0x7f58a1d7b991 in g_mutex_lock () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x7f58a1d39ed5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x7f58a1d3a0ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7f58a6c687be in QEventDispatcherGlib::processEvents
(this=0x7f588801ed50, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#5 0x7f58a6c3a0af in QEventLoop::processEvents
(this=this@entry=0x7f58908fce20, flags=...) at kernel/qeventloop.cpp:149
#6 0x7f58a6c3a3a5 in QEventLoop::exec (this=this@entry=0x7f58908fce20,
flags=...) at kernel/qeventloop.cpp:204
#7 0x7f58a6b36c5f in QThread::exec (this=) at
thread/qthread.cpp:537
#8 0x7f58a6b3932f in QThreadPrivate::start (arg=0x18c7780) at
thread/qthread_unix.cpp:349
#9 0x7f58a2663182 in start_thread (arg=0x7f58908fd700) at
pthread_create.c:312
#10 0x7f58a324930d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 3 (Thread 0x7f5883fff700 (LWP 16967)):
#0 0x7f58a1d7b639 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x7f58a1d7b989 in g_mutex_lock () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x7f58a1d391f8 in g_main_context_release () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x7f58a1d39f91 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7f58a1d3a0ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x7f58a6c687be in QEventDispatcherGlib::processEvents
(this=0x7f587c02df60, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#6 0x7f58a6c3a0af in QEventLoop::processEvents
(this=this@entry=0x7f5883ffee20, flags=...) at kernel/qeventloop.cpp:149
#7 0x7f58a6c3a3a5 in QEventLoop::exec (this=this@entry=0x7f5883ffee20,
flags=...) at kernel/qeventloop.cpp:204
#8 0x7f58a6b36c5f in QThread::exec (this=) at
thread/qthread.cpp:537
#9 0x7f58a6b3932f in QThreadPrivate::start (arg=0x1937400) at
thread/qthread_unix.cpp:349
#10 0x7f58a2663182 in start_thread (arg=0x7f5883fff700) at
pthread_create.c:312
#11 0x7f58a324930d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 2 (Thread 0x7f5892afc700 (LWP 10383)):
#0 0x7f58a1d7b62a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x7f58a1d7b989 in g_mutex_lock () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x7f58a1d390b0 in g_main_context_acquire () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x7f58a1d39ea5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x7f58a1d3a0ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x7f58a6c687be in QEventDispatcherGlib::processEvents
(this=0x7f588400c030, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#6 0x7f58a6c3a0af in QEventLoop::processEvents
(this=this@entry=0x7f5892afbe20, flags=...) at kernel/qeventloop.cpp:149
#7 0x7f58a6c3a3a5 in QEventLoop::exec (this=this@entry=0x7f5892afbe20,
flags=...) at kernel/qeventloop.cpp:204
#8 0x7f58a6b36c5f in QThread::exec (this=) at
thread/qthread.cpp:537
#9 0x7f58a6b3932f in QThreadPrivate::start (arg=0x19564b0) at
thread/qthread_unix.cpp:349
#10 0x7f58a266
[kmail2] [Bug 315568] kmail crash on startup
https://bugs.kde.org/show_bug.cgi?id=315568 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 315568] kmail crash on startup
https://bugs.kde.org/show_bug.cgi?id=315568 --- Comment #36 from RJVB --- Created attachment 86515 --> https://bugs.kde.org/attachment.cgi?id=86515&action=edit New crash information added by DrKonqi kmail (4.13) on KDE Platform 4.13.0 using Qt 4.8.6 - What I was doing when the application crashed: Restarted kmail after aborting an apparently locked imap synchronisation (gmail account) - Unusual behaviour I noticed: 1) an imap synchronisation apparently got locked 2) aborting the operation did not unlock the situation 3) kmail didn't actually quit after selecting the the Quit menu; the process kept running after closing all windows -- Backtrace (Reduced): #6 KStatusNotifierItem::setStatus (this=this@entry=0x24f9c70, status=KStatusNotifierItem::Active) at ../../kdeui/notifications/kstatusnotifieritem.cpp:160 #7 0x7f3010d4802c in KMail::KMSystemTray::setMode (this=0x24f9c70, newMode=1) at ../../kmail/kmsystemtray.cpp:168 #8 0x7f3010d5194b in KMKernel::toggleSystemTray (this=0x7fff3e339d30) at ../../kmail/kmkernel.cpp:2039 #9 0x7f3010d81caf in KMMainWidget::readConfig (this=this@entry=0x2813c40) at ../../kmail/kmmainwidget.cpp:859 #10 0x7f3010d90df8 in KMMainWidget::KMMainWidget (this=0x2813c40, parent=, aGUIClient=0x2419870, actionCollection=, config=...) at ../../kmail/kmmainwidget.cpp:269 -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 330847] New: crash after entering pw in duplicate authentication dialogue
https://bugs.kde.org/show_bug.cgi?id=330847 Bug ID: 330847 Summary: crash after entering pw in duplicate authentication dialogue Classification: Unclassified Product: Akonadi Version: 4.11 Platform: Mint (Debian based) OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: Mail Dispatcher Agent Assignee: kdepim-bugs@kde.org Reporter: rjvber...@gmail.com CC: vkra...@kde.org Application: akonadi_maildispatcher_agent (4.11) KDE Platform Version: 4.11.3 Qt Version: 4.8.6 Operating System: Linux 3.12.6-sabayon-amd64-rjvb x86_64 Distribution: LMDE Cinnamon Edition -- Information about the crash: - What I was doing when the application crashed: A mail had been sitting in my outbox, apparently because I had not noticed the authentication request. I cancelled the send from the progress popup in the lower right, and then used the "send queued messages" command. I entered my PW in the new dialogue that popped up, the message was sent OK, and then I saw the other password dialogue. After entering my PW in there, the mail send handler crashed. 2 things that strike me: - existing pw dialogues should be reused or closed if the operation that spawned them is aborted - I had sent an email through the same server moments before. Even when not storing passwords in a wallet, why not keep them in memory (this was at least the case for imap servers in the previous Kmail version I used, from KDE 4.8.5). -- Backtrace: Application: Mail Dispatcher Agent (akonadi_maildispatcher_agent), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [KCrash Handler] #6 0x7f386de8a344 in MailTransport::TransportJob::transport (this=this@entry=0x1eea2e0) at ../../mailtransport/transportjob.cpp:81 #7 0x7f386de8dbc0 in MailTransport::SmtpJob::startSmtpJob (this=0x1eea2e0) at ../../mailtransport/smtpjob.cpp:192 #8 0x7f386de8e48a in MailTransport::SmtpJob::doStart (this=0x1eea2e0) at ../../mailtransport/smtpjob.cpp:134 #9 0x7f386de8a444 in MailTransport::TransportJob::start (this=0x1eea2e0) at ../../mailtransport/transportjob.cpp:129 #10 0x00413377 in ?? () #11 0x00413f3c in ?? () #12 0x7f386ec2c87e in QObject::event (this=0x1e80500, e=) at kernel/qobject.cpp:1194 #13 0x7f386b0af75c in QApplicationPrivate::notify_helper (this=this@entry=0x1b22d60, receiver=receiver@entry=0x1e80500, e=e@entry=0x1ecb6c0) at kernel/qapplication.cpp:4567 #14 0x7f386b0b5dd0 in QApplication::notify (this=this@entry=0x70c16b10, receiver=receiver@entry=0x1e80500, e=e@entry=0x1ecb6c0) at kernel/qapplication.cpp:4353 #15 0x7f386d60549a in KApplication::notify (this=0x70c16b10, receiver=0x1e80500, event=0x1ecb6c0) at ../../kdeui/kernel/kapplication.cpp:311 #16 0x7f386ec1433d in QCoreApplication::notifyInternal (this=0x70c16b10, receiver=receiver@entry=0x1e80500, event=event@entry=0x1ecb6c0) at kernel/qcoreapplication.cpp:949 #17 0x7f386ec1789f in sendEvent (event=0x1ecb6c0, receiver=0x1e80500) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #18 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x1af7ea0) at kernel/qcoreapplication.cpp:1573 #19 0x7f386ec17d43 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1466 #20 0x7f386ec41bf3 in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236 #21 postEventSourceDispatch (s=0x1b22a20) at kernel/qeventdispatcher_glib.cpp:280 #22 0x7f386a5f7ea6 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x7f386a5f81f8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x7f386a5f829c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x7f386ec414b5 in QEventDispatcherGlib::processEvents (this=0x1af9800, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #26 0x7f386b14d896 in QGuiEventDispatcherGlib::processEvents (this=, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #27 0x7f386ec12f9f in QEventLoop::processEvents (this=this@entry=0x70c16a80, flags=...) at kernel/qeventloop.cpp:149 #28 0x7f386ec13295 in QEventLoop::exec (this=this@entry=0x70c16a80, flags=...) at kernel/qeventloop.cpp:204 #29 0x7f386ec188db in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1221 #30 0x7f386b0adf1c in QApplication::exec () at kernel/qapplication.cpp:3828 #31 0x7f386f254033 in Akonadi::AgentBase::init (r=0x1d608f0) at ../../akonadi/agentbase.cpp:706 #32 0x0040b710 in ?? () #33 0x7f386cb21995 in __libc_start_main (main=0x408d10, argc=3, ubp_av=0x70c16c28, ini
