I just went through glib2 sources and now I am quite sure, that this is a bug in glib2 not in evolution.
The man page for poll says: "On success, a positive number is returned; this is the number of structures which have non-zero revents fields (in other words, those descriptors with events or errors reported)". So if the peer closes a TCP connection while the thread is waiting for poll, then the poll call "succeeds" - it returns positive number 1. The errno is set on affected fd - POLLNVAL or other flag is set.
Unfortunately there is no code in glib2(gmain.c gpoll.c) that handles such a situation. I guess that the function g_main_context_check should if there is really something to read from the socket and possibly remove failed/closed TCP connection from the fd list.
I just went through glib2 sources and now I am quite sure, that this is a bug in glib2 not in evolution.
The man page for poll says: "On success, a positive number is returned; this is the number of structures which have non-zero revents fields (in other words, those descriptors with events or errors reported)". So if the peer closes a TCP connection while the thread is waiting for poll, then the poll call "succeeds" - it returns positive number 1. The errno is set on affected fd - POLLNVAL or other flag is set.
Unfortunately there is no code in glib2(gmain.c gpoll.c) that handles such a situation. I guess that the function g_main_ context_ check should if there is really something to read from the socket and possibly remove failed/closed TCP connection from the fd list.