There's not a single Evolution call in that trace, so it's not helpful. Which distro is this?

Might be NetworkManager-related.  Looks like libnm-glib has got at least two or three main loops running (Thread 3 & 5, maybe 4.  I don't know where Thread 2 came from.)  Maybe one of them is doing a blocking poll?

Evolution doesn't appear to be at fault on this one, perhaps other than the fact that we still use libnm-glib.

It's Fedora 9.

I've got no idea what it's doing at shutdown, but it's happening every time.

Is there some way I can kill just the nm-related thread to see if that helps?

I need to review GLib's shutdown semantics when multiple main loops are running.  If you'd like to do a little GDB debugging, I'd be interested in whether a breakpoint on g_main_loop_quit() is ever hit when you try to shutdown, and if so for which thread(s).

Another idea is to try disabling networking through nm-applet when Evolution is hung.  That's more of a longshot but it might jar the NM threads loose.  Of course I'm still not certain this is really NetworkManager-related at all.

Quitting Evolution then running /etc/init.d/NetworkManager stop had no effect.  I then killed /usr/sbin/nm-system-settings and nm-applet, which also had no effect.

gdb evolution
run
Ctrl+C
break g_main_loop_quit
cont
(quit Evolution)

Does not break.

Maybe there's some way of seeing what resource the __poll is blocked on?

Will also try killing GNOME components (g-s-d, seahorse, bonobo, DBus, etc.) and see if any of those do it.

A colleague suggested that maybe the window wasn't getting a proper close/quit event.

I had a quick look using xev, and assuming I'm not doing anything wrong, then he's right!

If I use xprop on the Evo window, grab the line matching _NET_WM_USER_TIME_WINDOW(WINDOW), then run xev -id with that hex number, I don't see any DestroyNotify event, whereas I do if I try the same method on a gedit window.

Also, to be more precise, when I say "hangs", then sidebar and toolbar go gray/disabled, the selected item in the mail list has its background go gray, and the mail preview pane stays with its white background.  It is totally unresponsive at this point, except to a TERM signal so far as I can tell.

I'll try again with another window manager just in case (I'm currently using Openbox).

Interesting.  When this kind of hang occurs on shutdown it's usually due to Camel going off in the weeds, but that would show up on a stack trace.

If you drag another window over and away from Evolution when it's hung like this, does the Evolution window repaint itself?

Now I'm starting to wonder if this might be a case of your window manager not getting along with Bonobo.

I think what happened was due to my IMAP server not responding.  I had 18,000 messages in my INBOX, and it was timing out when responding to IMAP commands like EXPUNGE.

Is this still an issue nowadays (3.2.3 or 3.4.3), or can this be closed as RESOLVED OBSOLETE?

Closing as per comment #9.