Bug 267541 - Gnome Clock crashes with backstrace
Gnome Clock crashes with backstrace
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gnome-panel (Show other bugs)
All All
high Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
Depends On:
  Show dependency treegraph
Reported: 2007-08-30 11:38 EDT by Marek Mahut
Modified: 2013-04-12 15:20 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2008-0045
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-23 09:18:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Backtrace from bug-buddy (9.37 KB, text/plain)
2007-08-30 11:39 EDT, Marek Mahut
no flags Details
~/.xsession-errors (15.13 KB, application/octet-stream)
2007-09-05 13:06 EDT, Marek Mahut
no flags Details
console output (422 bytes, text/plain)
2007-10-08 07:18 EDT, Marek Mahut
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 520111 None None None Never

  None (edit)
Description Marek Mahut 2007-08-30 11:38:44 EDT
Description of problem:

After setup some meeting in evolution, the gnome calendar clock crashes.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Click on clock applet to get the calendar
2. Bug-buddy pops up

Actual results:

ClockApplet crashes

Expected results:

ClockApplet shows me my meetings :)

Additional info:

Backtrace will follow.
Comment 1 Marek Mahut 2007-08-30 11:39:38 EDT
Created attachment 181281 [details]
Backtrace from bug-buddy

Just let me know if you need more information from me.
Comment 3 Ray Strode [halfline] 2007-09-05 11:36:46 EDT
Hi Marek,

I've built some packages here:


Can you give them a try, then attach ~/.xsession-errors ?
Comment 4 Marek Mahut 2007-09-05 13:05:22 EDT
Hey Ray,

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
calendar support?

Thank you.
Comment 5 Marek Mahut 2007-09-05 13:06:36 EDT
Created attachment 187731 [details]
Comment 6 Ray Strode [halfline] 2007-09-05 13:46:17 EDT
.xsession-errors didn't have the information I hoped it would in it.

Can you remove the clock from your panel, then

pkill clock-applet

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?
Comment 7 Marek Mahut 2007-09-05 14:56:40 EDT
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?
Comment 8 Ray Strode [halfline] 2007-09-05 15:34:29 EDT
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.
Comment 9 Marek Mahut 2007-10-08 07:18:04 EDT
Created attachment 219651 [details]
console output


Very very sorry for my late response! I missed somehow mail from bugzilla about
your comment. Here it is.

Comment 10 Ray Strode [halfline] 2007-11-15 09:32:30 EST
proposing for 5.2 fastrack.  devack
Comment 13 Ray Strode [halfline] 2008-01-07 13:55:57 EST
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.
Comment 14 Matthew Barnes 2008-01-07 15:06:34 EST
(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. :)
Comment 17 errata-xmlrpc 2008-01-23 09:18:10 EST
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.


Note You need to log in before you can comment on or make changes to this bug.