| Summary: | KOrgac reading Zimbra calendars via caldav crash constantly for almost all users | ||
|---|---|---|---|
| Product: | TDE | Reporter: | John A. Sullivan III <jsullivan> |
| Component: | tdepim | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | bugwatch, darrella |
| Priority: | P5 | ||
| Version: | 3.5.12 [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: |
Backtrace of korgac crashing
Another backtrace Another backtrace Yet another backtrace |
||
A backtrace would be essential for tracking down the root cause of this bug. 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 "-" "-" Hi, Tim. I did attach one. Sometimes we get one and sometimes we don't. Thanks - John (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! Created attachment 71 [details]
Another backtrace
I was able to catch another backtrace and have uploaded it to this report. Created attachment 72 [details]
Another backtrace
Created attachment 73 [details]
Yet another backtrace
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 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. 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. 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. 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 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! 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 *** |
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.