Bug 1011125

Summary:

Kmail locks up, runs by fits and starts

Product:

[Fedora] Fedora

Reporter:

Peter Gückel <pgueckel>

Component:

kdepim

Assignee:

Than Ngo <than>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

high

Docs Contact:

Priority:

unspecified

Version:

CC:

dvratil, fedora, jreznik, kevin, ltinkl, rdieter, rnovacek, smparrish, than

Target Milestone:

---

Target Release:

---

Hardware:

Unspecified

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2014-01-17 18:30:50 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Backtrace when kmail stalls while attempting to view an HTML message	none
Second backtrace when kmail stalls while attempting to view an HTML message	none
Backtrace when deleting a plain text message	none
Backtrace when deleting a second plain text message	none
Backtrace when deleting a third plain text message	none
Backtrace when deleting a fourth plain text message	none
Second backtrace when deleting that same fourth plain text message	none

Description Peter Gückel 2013-09-23 16:17:17 UTC

Description of problem:
When running kmail, it is set to get my mail at start-up, which works. When I try to select a message, however, the program locks up, no response, no active icons on the program menu, for around (subjective impression) 30 seconds, then the message is selected. If I try to open the message, click another message or click on a different directory (trash, sent, etc), the same thing happens. If I try to close the program, even, it fails to respond and the window manager asks whether it should terminate the program. If I decline, the program will close of its own accord within about 30 seconds.

I was thinking it could be akonadi, but kaddressbook also uses akonadi and it works fine. Could it be virtuoso/nepomuk? I have email indexing disabled, or, as it is called, suspended.

Version-Release number of selected component (if applicable):
kdepim-4.11.1-1.fc19.x86_64

How reproducible:
Run program; happens every time

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Peter Gückel 2013-09-29 19:39:54 UTC

https://bugs.kde.org/show_bug.cgi?id=325440

BTW, I have updated to kde-4.11.2.1

Comment 2 Graham TerMarsch 2013-10-03 19:35:11 UTC

Created attachment 807234 [details]
Backtrace when kmail stalls while attempting to view an HTML message

Stack trace taken w/gdb, while attempting to click on an HTML formatted e-mail.

Comment 3 Graham TerMarsch 2013-10-03 19:36:20 UTC

Created attachment 807235 [details]
Second backtrace when kmail stalls while attempting to view an HTML message

Same circumstances as previous backtrace; attempting to switch to view an HTML formatted e-mail.  KMail stalls, backtrace was taken.

Comment 4 Graham TerMarsch 2013-10-03 19:37:09 UTC

Created attachment 807236 [details]
Backtrace when deleting a plain text message

Attempting to delete a plain-text message.  KMail stalls, and after ~20s I fired up gdb and took this backtrace.

Comment 5 Graham TerMarsch 2013-10-03 19:38:04 UTC

Created attachment 807237 [details]
Backtrace when deleting a second plain text message

Same circumstances as 03, but while attempting to delete a different plain text message.

Comment 6 Graham TerMarsch 2013-10-03 19:38:48 UTC

Created attachment 807238 [details]
Backtrace when deleting a third plain text message

Same circumstances as 03 and 04... in the process of deleting a plain-text message, and kmail stalls out.

Comment 7 Graham TerMarsch 2013-10-03 19:39:23 UTC

Created attachment 807239 [details]
Backtrace when deleting a fourth plain text message

Similar circumstances... deleting plain text message, kmail stalls, backtrace was taken.

Comment 8 Graham TerMarsch 2013-10-03 19:40:33 UTC

Created attachment 807240 [details]
Second backtrace when deleting that same fourth plain text message

After having taken backtrace 06, I waited another few seconds, and then took this second backtrace.  UI had still not yet responded to my hitting "d" to delete the message.

Comment 9 Graham TerMarsch 2013-10-03 19:44:23 UTC

W.r.t. those backtraces I just added....

The first two (807234, 807235) were taken on Oct 1st, while attempting to view an HTML formatted e-mail.  I do not have Akonadi debug info for those traces.

The other ttachments (807236 through 807240) were all taken just a few moments ago.  While kmail was stalled, the Akonadi Console debug screen showed _nothing_ in the way of communication w/Akonadi while the UI was stalled.  Once the UI started to do something, the debugger quickly whizzed along with things, but that was only _after_ the UI began to do something.

First few items in said debug output from Akonadi were as follows:

kmail2-1045703580 (0xa37120) 188 UID FETCH 567805 FULLPAYLOAD ALLATTR ANCESTORS 1 EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME ATR:ErrorAttribute) 
akonadi_maildir_resource_1 (0x9bb570) 5436 UID FETCH 567805 CACHEONLY ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) 
akonadi_maildir_resource_1 (0x9bb570) * 567805 FETCH (UID 567805 REV 0 REMOTEID "1380820200.R219.galvatron.internal.example.com" MIMETYPE "message/rfc822" COLLECTIONID 1386 SIZE 82518 DATETIME "03-Oct-2013 17:10:00 +0000" FLAGS () ANCESTORS ((1386 "MyCustomer") (1319 "Work") (1302 "/home/graham/.local/share/local-mail") (0 ""))) 
akonadi_maildir_resource_1 (0x9bb570) 5436 OK UID FETCH completed

Comment 10 Daniel Vrátil 2013-10-04 09:34:01 UTC

Hi,

thanks for all the debugs.

comment #2: looks like a problem in WebKit, nothing much we can do about
comment #3: looks like a clean up of a rather big QMap
comments #4, #5, #6, #7 and #8: looks like a problem with a...clipboard? Sorry, Google is not much helpful and I have no idea what could be causing this. Are there any errors in ~/.xsession-errors?

Comment 11 Peter Gückel 2013-10-04 16:02:53 UTC

I looked in my .xsession-errors and found some curious stuff:

There were lots of these, some with my email:
akonadi_pop3_resource_0(1539)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = 

There were a lot of these; they look significant (these directories DO exist):
AkonadiAgentServer(1531)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/peter/.local/share/local-mail/inbox" 
AkonadiAgentServer(1531)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/peter/.local/share/local-mail/inbox" 
AkonadiAgentServer(1531)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/peter/.local/share/local-mail/trash" 
AkonadiAgentServer(1531)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/peter/.local/share/local-mail/trash" 
 itemMoved 404 
QDir::mkpath: Empty or null file name(s)
AkonadiAgentServer(1531)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/peter/.local/share/local-mail/trash" 
AkonadiAgentServer(1531)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/peter/.local/share/local-mail/trash" 
knode(8107)/kdepimlibs (kmime) KMime::Types::Mailbox::setAddress: Invalid address 

And lots of QPainter not active stuff. I don't understand much in the xsession file, but those things look suspicious to me.

Comment 12 Daniel Vrátil 2013-10-04 16:13:32 UTC

The KIO warning is fine, that's not an error. The KDirWatchPrivate::removeEntry() warnings are only debug infos saying that the class is not watching (unfortunate wording, sounds like error, but it's not) and finally the KMime::Types is new to me, but does not cause any troubles with clipboard.

Comment 13 Peter Gückel 2013-11-16 01:44:20 UTC

I have been using Fedora 20ß for 2 days and I have not yet seen this.

Perhaps it has been fixed?

Comment 14 Peter Gückel 2014-01-17 18:30:50 UTC

I think I can feel confident in closing this, as it appears to be solved in f20.