Bug 175749 - clock-applet hangs when attempting to load calendar
clock-applet hangs when attempting to load calendar
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Malcolm
Depends On:
Blocks: FC5Target
  Show dependency treegraph
Reported: 2005-12-14 11:14 EST by James Laska
Modified: 2013-09-02 02:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-11 17:51:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Laska 2005-12-14 11:14:16 EST
# 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 11:28:10 EST
> 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 11:44:47 EST
Thanks; I'm seeing this as well and am debugging...
Comment 3 Dave Malcolm 2005-12-15 15:40:16 EST
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 15:41:48 EST
Incidentally, I'm correctly seeing my tasks and appointments when I do manage to
make it visible
Comment 5 Nalin Dahyabhai 2005-12-16 13:02:46 EST
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 09:48:26 EST
This appears to be working now in rawhide-20051221 which includes

Comment 7 Dave Malcolm 2006-01-11 17:51:44 EST
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.