Red Hat Bugzilla – Bug 267541
Gnome Clock crashes with backstrace
Last modified: 2013-04-12 15:20:04 EDT
Description of problem:
After setup some meeting in evolution, the gnome calendar clock crashes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Click on clock applet to get the calendar
2. Bug-buddy pops up
ClockApplet shows me my meetings :)
Backtrace will follow.
Created attachment 181281 [details]
Backtrace from bug-buddy
Just let me know if you need more information from me.
I've built some packages here:
Can you give them a try, then attach ~/.xsession-errors ?
Many thanks for prompt action. This package resolve the problem completely, but
now, I can't see any of my calendars in there. Is there any way to fix it with
Created attachment 187731 [details]
.xsession-errors didn't have the information I hoped it would in it.
Can you remove the clock from your panel, then
let that run, and then readd the clock to your panel? After doing that, click
on your calendar. When you've done that can you copy and paste the output sent
to the terminal and paste it into a comment in this report?
After restart of my gnome session, I confirm that it's working without problem.
Your build resolved this bug completely.
What are chances to have this fix in 5.1?
This definitely won't make 5.1, unfortunately.
Would you still mind doing comment 6? my patch worked around an assertion
failing, but it would be good to know why the assertion is failing, to see if we
can fix the problem at its source.
Created attachment 219651 [details]
Very very sorry for my late response! I missed somehow mail from bugzilla about
your comment. Here it is.
proposing for 5.2 fastrack. devack
So looking at this further, it seems the zimbra backend for the calendar is
sending multiple view-done signals per query which is confusing the clock applet.
It looks like the zimbra backend emits that signal from it's _sync function
which gets called repeatedly.
I don't know what the rules of the backend api are with regard to that signal,
but I suspect it's a bug the backend is emitting the signal twice. CCing mbarnes.
At any rate, the panel shouldn't crash as a result of that, so I've built a fix
for that issue in gnome-panel-2.16.1-7.el5
Marking MODIFIED for QA.
(In reply to comment #13)
> I don't know what the rules of the backend api are with regard to that signal,
> but I suspect it's a bug the backend is emitting the signal twice. CCing mbarnes.
I agree. As far as I can tell, "view-done" signals when the ECalView is done
updating stuff and should only be emitted once at the end of a query. The
Zimbra backend should not be emitting the signal repeatedly. I'll file an
upstream bug about this.
An alternate approach to the applet crash might be to just disconnect from the
"view-done" signal when assigning to source->completed_query in the signal
handler. But you probably don't care anymore at this point. :)
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.