First thread is querying the calendar, and several other threads are trying to open the calendar.  I have a hunch that evolution-data-server is crashing and so the process never responds to the clock applet.  I also started noticing this myself after I installed evolution-mapi, but that may be a coincidence.

Can you try connecting GDB to the evolution-data-server process and then repeat this applet hang?  Let's see if e-d-s segfaults.

Already did it the backtrace is:

+ Trace 212458

Was it with a calendar requiring authentication? If yes, does it happen with 2.25.90? I fixed some similar bug there.

one ubuntu user confirmed having the issue on GFNOME 2.25.90 using non authentified calendars, only local and publuc webdav ones are configured 

the user has calendar which require authentification configured but not enabled

do you need extra details out of looking for e-d-s crashers?

do you need extra details out of looking for e-d-s crashers?

sorry about the duplicate comments enough spam for today

just got the issue on jaunty using GNOME 2.25.90, evolution-data-server was running for a while and didn't crash or exit, evolution was still working correctly, using no non-local calendar

I have two google calendars which need authentication, and I get the issue as well. However, it it still happens if I disable the calendars in evo (I didn't delete them, though).

If something is wrong in the applet code itself, I'd appreciate help. But my guess would be something in eds, though.

what informations would be useful there? knowning that the issue happen often and for lot of users in GNOME 2.25.90, that e-d-s doesn't crash and that it hangs gnome-panel which pretty much stuck users

Created attachment 128661 [details] [review]
proposed eds patch

for evolution-data-server;

It crashes in libical. Not for me, even I see the same thing, with my tasks. They have set UTC timezone, and this one doesn't have inner component, thus we are passing NULL into icalcomponent_new_clone, which is considered as a fatal error, thus libical aborts. (once again, not for me - thus it depends on the configure flags). Nonetheless, this fixes it.

Recommendation for gnome-applet: I do not know how much possible, but if you will do e_cal_get_query on other than main thread, then a) you'll not block whole panel on slow calendars/tasks; b) you will be notified properly of the eds crash; c) (-) you'll need more accurate async code, which could be difficult/boring/....
If I recall correctly, notification of crashed eds are receive to the program on idle, thus when your main thread is "busy", then this notification waits to be delivered, and you've just a bad luck here.

(In reply to comment #13)
> Recommendation for gnome-applet: I do not know how much possible, but if you
> will do e_cal_get_query on other than main thread, then a) you'll not block
> whole panel on slow calendars/tasks; b) you will be notified properly of the
> eds crash; c) (-) you'll need more accurate async code, which could be
> difficult/boring/....

Hrm. Can't we get some e_cal_get_query_async() function instead? :-) It sounds bad to require knowledge of the internals like this to use the API.

(In reply to comment #14)
> (In reply to comment #13)
> > Recommendation for gnome-applet: I do not know how much possible, but if you
> > will do e_cal_get_query on other than main thread, then a) you'll not block
> > whole panel on slow calendars/tasks; b) you will be notified properly of the
> > eds crash; c) (-) you'll need more accurate async code, which could be
> > difficult/boring/....
> 
> Hrm. Can't we get some e_cal_get_query_async() function instead? :-) It sounds
> bad to require knowledge of the internals like this to use the API.

I do not think these are any specific internals of Evolution. The b) is about ORBit, not about Evolution. And the rest is quite common for any slow operations, isn't it?

(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Recommendation for gnome-applet: I do not know how much possible, but if you
> > > will do e_cal_get_query on other than main thread, then a) you'll not block
> > > whole panel on slow calendars/tasks; b) you will be notified properly of the
> > > eds crash; c) (-) you'll need more accurate async code, which could be
> > > difficult/boring/....
> > 
> > Hrm. Can't we get some e_cal_get_query_async() function instead? :-) It sounds
> > bad to require knowledge of the internals like this to use the API.
> 
> I do not think these are any specific internals of Evolution. The b) is about
> ORBit, not about Evolution. And the rest is quite common for any slow
> operations, isn't it?

How am I supposed to know it's slow? Or that it uses ORBit? :-)
(if it's slow, it should get an async version, that's my point)

hum, the change is not in 2.25.91? any reason for not commiting it to svn?

(In reply to comment #17)
> hum, the change is not in 2.25.91? any reason for not commiting it to svn?

It waits for its review, even it's a one-liner. (To be honest, I forgot of it.)

I'm raising Priority and set the target to gnome-2.26, I think Andre will catch it in its showstopper list :)

What's the proper way of requesting an async version of e_cal_get_query()? Do you want me to open a new bug, or is this one fine?

(In reply to comment #20)
> What's the proper way of requesting an async version of e_cal_get_query()? Do
> you want me to open a new bug, or is this one fine?

From my point of view it's an API extension, and as such deserves its own bug report. (It doesn't mean I think it'll be done.)

I filed bug 572169. Thanks.

Committed to trunk. Committed revision 10073.

Sebastien told me it works fine for one of his testers, thus putting it in.

*** Bug 572197 has been marked as a duplicate of this bug. ***