Bug 135544

Summary:	Kopete hangs under high load
Product:	[Unmaintained] kopete	Reporter:	Michał ,,KNT'' Gorycki <knt>
Component:	general	Assignee:	Kopete Developers <kopete-bugs-null>
Status:	RESOLVED REMIND
Severity:	normal	CC:	tuju
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Michał ,,KNT'' Gorycki 2006-10-12 23:29:06 UTC

Version:           0.12.3 (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages

When Kopete starts up from a restored session, and I start to log in while my system is still under heavy load, Kopete will hang for sure. When it has to open messages sent to me while I was offline the system dosen't need to be stressed for this to happen (at least as I check after I notice the hangup).
Sometimes it hangs showing the password dialog for my only Jabber account whitch hasn't a password stored (I have four Jabber accounts, one ICQ and one Gadu-Gadu).
Then I have no other way than to kill the proces.

I don't know if this has any connection with this but when I start Kopete from the console I notice a lot of:

QDateTime::fromString: Parameter out of range

showing up.

Comment 1 Bram Schoenmakers 2006-10-13 00:16:16 UTC

Do you use KWallet for storing passwords? It may be similar to bug 133795.

Comment 2 Michał ,,KNT'' Gorycki 2006-10-13 09:50:40 UTC

Yes, I do use KWallet, but i think thats where similarities end. I connect the hangups with system load.

Comment 3 Bartosz "Inc!" Kielczewski 2006-11-10 00:53:39 UTC

I suffer from the same problem - it hangs while starting up (I have a shortcut in autostart) and hangs on delivery of due messages when I was offline as well. "QDateTime::fromString: Parameter out of range" is also visible when I start it from the console. Specs: gentoo, amd64, kde 3.5.5. So, since Michal is on Debian and on different arch, maybe it has something to do with our locale settings (I assume he's using Polish)?

Comment 4 Michał ,,KNT'' Gorycki 2006-12-04 09:13:04 UTC

Is there a way then for Kopete to ignore localization without restarting whole KDE?

Comment 5 Bram Schoenmakers 2006-12-04 13:03:08 UTC

In the shell:

KDE_LANG="en_US" kopete

Comment 6 Michał ,,KNT'' Gorycki 2006-12-04 13:46:31 UTC

(Evety thing done in a stressed system)
First I closed an old Kopete process

And then
> KDE_LANG="en_US" kopete &

After a while:

kopete: ERROR: Communication problem with kopete, it probably crashed.

[1]+  Exit 255                KDE_LANG="en_US" kopete

I repeated thinking that there was something stale left
> KDE_LANG="en_US" kopete &

A lot of "QDateTime::fromString: Parameter out of range" appeared, but kopete wasn't responding. So:
> killall kopete
[1]+  Done                    KDE_LANG="en_US" kopete

And again
> KDE_LANG="en_US" kopete &

Whitch only gave:
kopete: ERROR: Communication problem with kopete, it probably crashed.

[1]+  Exit 255                KDE_LANG="en_US" kopete

Reppeating againg gave me finaly a working Kopete. So I connect all my protocols. Kdewallet ask for my password. I input it and another window asking for my password appeared (one of the accounts isn't in the wallet. The cursor blinks once and then Kopete stops responding. So I kill Kopete and start it again without localisation. This time Kopete hangs after I input the second password, but only for a few seconds and it works normaly since then.
To sumarize the above description is identical for running a localised process.

Comment 7 Michał ,,KNT'' Gorycki 2007-03-12 19:59:22 UTC

Additionaly I've got an SIGBART when I recived a message while moving a ~700MB file.

Comment 8 Matt Rogers 2007-09-12 05:01:24 UTC

hangs are not crashes. However, backtraces from when Kopete hangs would be useful. Please read http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports for more details.

Comment 9 Bram Schoenmakers 2007-12-10 00:11:12 UTC

Can you reproduce and if yes, can you provide a backtrace?

Comment 10 Matt Rogers 2008-02-07 05:30:59 UTC

We're still waiting for more information. Please provide a backtrace of when the hang occurs as described in comment #8. Once you have that, please paste it into  a comment and then reopen the bug.

Thanks