By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 486 - KOrgac reading Zimbra calendars via caldav crash constantly for almost all users
Summary: KOrgac reading Zimbra calendars via caldav crash constantly for almost all users
Status: RESOLVED DUPLICATE of bug 812
Alias: None
Product: TDE
Classification: Unclassified
Component: tdepim (show other bugs)
Version: 3.5.12 [Trinity]
Hardware: All Linux
: P5 major
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2011-07-19 12:57 CDT by John A. Sullivan III
Modified: 2012-10-19 15:24 CDT (History)
2 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:


Attachments
Backtrace of korgac crashing (6.30 KB, application/octet-stream)
2011-07-19 12:57 CDT, John A. Sullivan III
Details
Another backtrace (8.17 KB, application/octet-stream)
2011-07-20 13:49 CDT, John A. Sullivan III
Details
Another backtrace (5.40 KB, application/octet-stream)
2011-07-26 09:44 CDT, John A. Sullivan III
Details
Yet another backtrace (5.40 KB, application/octet-stream)
2011-07-26 09:45 CDT, John A. Sullivan III
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John A. Sullivan III 2011-07-19 12:57:11 CDT
Created attachment 70 [details]
Backtrace of korgac crashing

We run KOrgac for all our users connecting to their Zimbra calendars to provide desktop popup reminders.  It autostarts upon session start.  It immediately crashes for virtually all users.  Every once in a while, we receive some past due reminders and then it crashes.  We are often not able to obtain a backtrace but instead get the following message:

This backtrace appears to be of no use.
This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash.

Sometimes we are able to take a backtrace and I will attach one.

We are running:
korganizer-trinity                    4:3.5.12-0debian6+r1178442-1 

on a combination of Lenny and Squeeze.
Comment 1 Timothy Pearson 2011-07-19 13:09:00 CDT
A backtrace would be essential for tracking down the root cause of this bug.
Comment 2 John A. Sullivan III 2011-07-19 13:17:07 CDT
I scoured Zimbra's mailbox.log file for clues but see nothing that looks like a
problem.  I do see this in the nginx.log file:

2011/07/19 14:01:25 [info] 26213#0: *107028 client closed prematurely
connection while SSL handshaking, client: 172.29.2.1, server:
2011/07/19 14:01:25 [info] 26213#0: *107026 client 172.29.2.1 closed keepalive
connection
2011/07/19 14:01:25 [info] 26213#0: *107033 client closed prematurely
connection while SSL handshaking, client: 172.29.28.1, server:
2011/07/19 14:01:25 [info] 26213#0: *107032 client 172.29.2.1 closed keepalive
connection
2011/07/19 14:01:25 [info] 26213#0: *107029 client closed prematurely
connection while SSL handshaking, client: 172.29.2.1, server:
2011/07/19 14:01:25 [info] 26213#0: *107027 client 172.29.2.1 closed keepalive
connection

However, I think this is a symptom rather than cause.  The timestamp looks to
be just after the crash and not before.

I do see this in nginx.access.log:

172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Calendar/ HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Tasks HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/teamshare@pacifera.com HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Financial%20Calendar HTTP/1.1" 302 154 "-"
"libcurl-agent/0.1"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Calendar/ HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Financial%20Calendar HTTP/1.1" 302 154 "-"
"libcurl-agent/0.1"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Tasks HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/teamshare@pacifera.com HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Calendar/ HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Financial%20Calendar HTTP/1.1" 302 154 "-"
"libcurl-agent/0.1"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/jsullivan@pacifera.com/Tasks HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - jsullivan@pacifera.com [19/Jul/2011:14:01:25 -0400] "OPTIONS
/dav/teamshare@pacifera.com HTTP/1.1" 302 154 "-" "libcurl-agent/0.1"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
172.29.2.1 - - [19/Jul/2011:14:01:25 -0400] "-" 400 0 "-" "-"
Comment 3 John A. Sullivan III 2011-07-19 13:18:10 CDT
Hi, Tim.  I did attach one. Sometimes we get one and sometimes we don't.  Thanks - John
Comment 4 Timothy Pearson 2011-07-19 14:36:08 CDT
(In reply to comment #3)
> Hi, Tim.  I did attach one. Sometimes we get one and sometimes we don't. 
> Thanks - John

Sorry, didn't see it at first.

Thanks for the additional info!
Comment 5 John A. Sullivan III 2011-07-20 13:49:39 CDT
Created attachment 71 [details]
Another backtrace
Comment 6 John A. Sullivan III 2011-07-20 13:50:08 CDT
I was able to catch another backtrace and have uploaded it to this report.
Comment 7 John A. Sullivan III 2011-07-26 09:44:48 CDT
Created attachment 72 [details]
Another backtrace
Comment 8 John A. Sullivan III 2011-07-26 09:45:23 CDT
Created attachment 73 [details]
Yet another backtrace
Comment 9 John A. Sullivan III 2011-07-26 09:47:09 CDT
I've posted a couple of more backtraces.  I realize it is probably all hands to the pump to get the new release out but any idea when we might have a fix for this? It is rather embarrassing as virtually all of our clients (all use Trinity) are crashing daily.  Thanks - John
Comment 10 Timothy Pearson 2011-07-26 13:22:13 CDT
This looks like it is buried within Qt and system libraries, so a "quick fix" is not available.  I will look into the problem as I have time.

It is possible that the problem is fixed in our SVN, but Debian Squeeze nightly build packages are not yet available.
Comment 11 John A. Sullivan III 2011-08-10 08:16:54 CDT
It seems that crashes are frequently but not always associated with this error:

2011-08-10 09:01:33,920 ERROR [btpool0-32804://zimbra.pacifera.com/dav/user@company-co.com/Calendar] [name=user@company-co.com;aname=user@company-co.com;ip=172.x.x.73;ua=libcurl-agent/0.1;] dav - error handling method REPORT

I also tried unsuccessfully to isolate the problem.  The results do not make a lot of sense to me but they may mean something to you.  Here is the information from our internal ticket:

I tried several different approaches to try to isolate this error.  I see very little in the error logs. I did see some suspicious things in the nginx logs.

I tried bypassing NGINX by specifying URIs such a:
caldavs://zimbra01.pacifera.com:8443/dav. . . .

That initially seemed to work although it generated several error about it not being a valid URL per calendar but the calendars displayed and KOrgac did not crash.

I then tried reveting to zimbra instead of zimbra01.  I also tried caldav://zimbra01.pacifera.com:8080 and without the :8080.  All those caused crashes in KOrganizer.  I the returned to :8443 but now Korganizor crashes immediately :( Strangely, KOrgac is still running as of this writing.

I did find an error for Pacifera (no other companies) where our teamshare calendar was specified as carddavs instead of caldavs and have corrected that.  However, I do not think that was involved in this troubleshooting round because I disabled that calendar as part of the troubleshooting because of some suspicious messages about it.
Comment 12 Timothy Pearson 2011-08-10 13:26:12 CDT
Work on this bug has been suspended pending completion of the nightly builds from SVN for Debian Squeeze.

If you can set up a test system and install from those nightly builds (after they are available) to see if the problem persists it would be of great help.  There have been many bugfixes included in Trinity since 3.5.12, and it is quite possible that some of these sporadic crashes have been resolved through changes in core components.
Comment 13 John A. Sullivan III 2011-11-22 17:42:43 CST
Hello, all.  This is probably the most important bug on our list.  With the huge and appreciated push to get 3.5.13 out the door, would it be possible to knock this one out? Thanks - John
Comment 14 Timothy Pearson 2012-05-14 01:41:10 CDT
As stated before all the backtraces are indicating a problem in xcb or other core Xorg libraries/interfaces.  Does the application fail with a SIGSEGV or a SIGABRT?  If the latter, it is quite possible that this bug was related to Xorg and threading and should already be knocked out in GIT.

Thanks!
Comment 15 Timothy Pearson 2012-05-25 22:35:58 CDT
I'm going to tentatively mark this bug as a duplicate of 812, as I believe the underlying cause to be the same.  If this bug persists in R14.0 PLEASE unmark this as a duplicate and bump the priority!

Tim

*** This bug has been marked as a duplicate of bug 812 ***