I found out that the "cal-opened" signal is not emitted when a user is asked for a password and he/she cancels the prompt. In this case the signal is never emitted, and for example itip-formatter is thinking it's doing something, but it isn't, in an "infinite" waiting.

Steps:
a) either forget a password on one of your remote calendars which requires
   a password or configure for example a fake CalDAV calendar with:
   url: caldav://aaa.bbb.ccc/ddd
   username: xxx
b) on any prompt for a password on this calendar hit Cancel (or press Esc)
c) go to mailer
d) select a meeting invitation mail

itip-formatter is using all configured calendars to check whether the event is already stored there, doing e_cal_open_async and "waiting" until all calendars are opened, either properly or not, discovering this in cal-opened signal handler. As this is never called when one cancels the password prompt, itip-formatter never finishes its waiting for the signal (which is done async, thus the backtrace doesn't show anything, and CPU usage is low).

The 2.28 works properly in this case, so I'm calling this a regression.