Description of problem:
After using evolution for a while, I get to a point when I can no longer send
mail. Clicking on "Send/Recieve" hangs waiting for the SMTP transaction to
complete, which doesn't. I attached a screenshot of that dialog. Trying to
quit out of evolution at this point just hangs. killall evolution is the only
Version-Release number of selected component (if applicable):
2 for 2 so far since installing RHEL5 Beta2
Steps to Reproduce:
1. start evolution
2. use for a while
3. click "send/receive" and watch the SMTP send "waiting"
no mail gets sent;
So, to get out of this, one must quit evolution. BUT, evolution hangs exiting.
killall evolution. Upon restart, sending mail works again.
Created attachment 142312 [details]
screenshot of the send/receive popup
I'm finding myself having to "killall evolution" at least 6 times a day now.
I'd say that's a useability issue. Probably something that needs to get fixed
before we ship IMHO. Setting blocker to ?
I have this issue constantly also. Beta2.
It is worth noting that I have other issues with evolution (every quit causes a
crash and bug buddy pops up, find contacts does not work by any field, etc.)
I will open other bzs on those
*** Bug 219719 has been marked as a duplicate of this bug. ***
As described in Bug 219819, I can trigger this pretty readily on some machines
by performing two send/receives in quick succession or by performing a
send/receive right after a single mail send. In other words, the problem occurs
immediately instead of after a few hours.
For what it's worth, the fedora evolution has, so far, not shown me this error.
I found a couple similar upstream bugs, but there's been no progress on either
of them. One was from an Ubuntu user.
Its also mentioned in:
Corresponding for fc6 is bug 208724
Created attachment 145255 [details]
Fix for EMsgPort race
I figured this out. Its a race condition in the new EMsgPort implementation.
e_msgport_wait() saves the message in msgport->cache and returns it later in
e_msgport_get(). However, two threads can end up running e_msgport_wait() (if
two threads are waiting and two messages are put), which will result in cache
being overwritten with the last message.
This patch fixes it by making cache a list.
I see the same problem on FC6. Would be happy to test this given packages.
Built fix in evolution-data-server-1.8.0-15.el5
This bug has gone away for me with the new package, but since it's such a deep
bug, could you retest this bug for me John? Or someone else who was experiencing
FWIW, I've had numerous reports from Fedora Core 6 users that this patch has
solved the same hang-on-exit and hang-on-send/receive issues for them.
I have used Evo in latest nightly builds of RHEL5 client, and this bug also
seems to be gone.
I upgraded to the latest [2.8.0-33.el5] and all seems happy! Thanks!