Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 175749 - clock-applet hangs when attempting to load calendar
Summary: clock-applet hangs when attempting to load calendar
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution-data-server
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Malcolm
QA Contact:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-12-14 16:14 UTC by James Laska
Modified: 2013-09-02 06:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-01-11 22:51:44 UTC

Attachments (Terms of Use)

Description James Laska 2005-12-14 16:14:16 UTC
# RPMS gnome-panel-2.13.2-1.1.i386 evolution-data-server-1.5.2-1.1.i386

Steps to reproduce:
1) remove any running clock applets
2) from a terminal type ...
   $ ltrace -s256 -f -S -o /tmp/clock-applet.ltrace /usr/libexec/clock-applet
3) add clock applet to panel by right clicking panel and selecting "Add to panel
4) click the clock applet 

Expected results:
drop down calendar appears showing any evolution VTODO and VEVENTs

Actual results:
no drop down calendar dialog displays, the applet is still alive and has a
depressed button look to it (as if the calendar did display).  

Using ltrace it appears to hang when writing to a socket ...

4109 SYS_socketcall(1, 0xbfba3c00, 0x94bb4c, 0x8ce57c0, 0x8ce9588)           = 14
4109 g_str_equal(0x8ce28d8, 0x4d80ee, 0xbfba2630, 0x94bb4c, 0xbfba23d0)      = 1
4109 g_str_hash(0x4d80fc, 0x4d80ee, 0xbfba2630, 0x94bb4c, 0xbfba23d8)        =
4109 g_str_equal(0x8ce28b8, 0x4d80fc, 0xbfba2630, 0x94bb4c, 0xbfba23d8)      = 1
4109 g_str_hash(0x4d80ee, 0xbfba23c8, 4, 0x94bb4c, 0xbfba23d8)               =
4109 g_str_equal(0x8ce28d8, 0x4d80ee, 4, 0x94bb4c, 0xbfba23d8)               = 1
4109 g_str_hash(0x4d80fc, 0xbfba23a4, 0x8ce28c8, 0x94bb4c, 0x8ce28c8)        =
4109 g_str_equal(0x8ce28b8, 0x4d80fc, 0x8ce28c8, 0x94bb4c, 0x8ce28c8)        = 1
4109 SYS_writev(14, 0x8ce55a8, 2, 2, 0x7d2ff4)                               = 230
4109 SYS_futex(0x8ce1914, 0, 1, 0, 1)                                        = -4

For a full listing of the ltrace output see

Please advise if there are any additional debugging steps you'd like me to perform.

Comment 1 Ray Strode [halfline] 2005-12-14 16:28:10 UTC
> 4109 SYS_futex(0x8ce1914, 0, 1, 0, 1)

I think that may be some sort of thread lock contention. The first 0 there means
this is doing a FUTEX_WAIT operation and the second 0 means block indefinitely
until the lock is released.  

The -4 means EINTR (it stopped blocking not because the lock was available, but
because it got signal).

Comment 2 Dave Malcolm 2005-12-14 16:44:47 UTC
Thanks; I'm seeing this as well and am debugging...

Comment 3 Dave Malcolm 2005-12-15 20:40:16 UTC
I get the simple part of the symptoms reported in the bug; I'm seeing a possible
problem in position_calendar_popup; looks like it might simply be picking a
bogus y coordinate and the calendar popups up offscreen.

This is with a Top orientation panel, using metacity.

If I mess around with the orientation in Panel properties, I can get the
calendar popup to appear at times, albeit in the wrong location (if I change it
whilst the calendar visibility toggle is in a "depressed" state, then the
calendar popup appears but in the location relating to the previous panel

Possibly also a bad window manager interaction; the panel code tries to pick a
good location for the calendar popup window, and calls:
  gtk_window_move (GTK_WINDOW (window), x, y);
  gtk_window_set_gravity (GTK_WINDOW (window), gravity);
  gtk_window_present (GTK_WINDOW (window));

Comment 4 Dave Malcolm 2005-12-15 20:41:48 UTC
Incidentally, I'm correctly seeing my tasks and appointments when I do manage to
make it visible

Comment 5 Nalin Dahyabhai 2005-12-16 18:02:46 UTC
I can confirm that it's appearing off-screen.  I'm using twm, and the title bar
it gives to the calendar window is partially on-screen, on the lower right.

Don't know if it's useful or not, but running xwininfo against it, on a 1280x960
display, gives this information:
  Absolute upper-left X:  1020
  Absolute upper-left Y:  969
  Relative upper-left X:  0
  Relative upper-left Y:  23
  Width: 262
  Height: 194
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1020+969  --2+969  --2--203  +1020--203
  -geometry 262x194--4+944

Comment 6 James Laska 2005-12-21 14:48:26 UTC
This appears to be working now in rawhide-20051221 which includes


Comment 7 Dave Malcolm 2006-01-11 22:51:44 UTC
Working for me as well; I'm going to resolve this as fixed in rawhide.  Please
reopen it if symptoms persist. 

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