Red Hat Bugzilla – Bug 163348
clock-applet freezes . . .
Last modified: 2007-11-30 17:11:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Epiphany/1.6.3
Description of problem:
The clock-applet freezes, leading me to believe that it still really is 13:38 (or whatever time).
I can't reproduce this, but this is the second time this has happened.
The machine I am running it on is not rebooted very often.
An strace of the process shows no activity, not even a multitide of gettimeofday calls.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This is pretty important - you need to be able to trust the time on a clock.
It's just frozen again!
Twice in one day!
Best thing to try is to get a stack trace of the clock-applet process when its
frozen - don't forget to install the gnome-panel-debuginfo package first
Created attachment 119354 [details]
gdb /usr/libexec/clock-applet 2672
Output from gdb thread apply all bt.
It doesn't look very useful..
Created attachment 119757 [details]
stack trace of frozen clock
This one looks better!
This shouldn't be NEEDINFO_REPORTER, and I can't change this back to ASSIGNED.
Created attachment 120456 [details]
A decent stracktrace
Another day, another "WHAT?! IT CAN'T BE TWELVE O'CLOCK!!"
This stack trace looks good. Highlights:
#2 0x0366fadc in open_calendar (ecal=0x95d3200, only_if_exists=Variable
"only_if_exists" is not available.
#5 0x08056d64 in calendar_sources_load_sources (sources=Variable "sources" is
#55 0x0032dec4 in panel_applet_factory_main_closure (
iid=0x805780c "OAFIID:GNOME_ClockApplet_Factory", applet_type=156384624,
closure=Variable "closure" is not available.
I know you're busy, but not being able to rely on a desktop clock for
timekeeping is a problem.
I think this is an evolution-data-server bug that was fixed quite some time ago.
Are you still seeing this problem?
I saw it twice last week. Not sure if the strace was the same..
I only see this on one box, so closing.