After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 673095 - Should call SoupSessionAsync functions in soup thread only
Should call SoupSessionAsync functions in soup thread only
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Mail
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
: 679241 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-03-29 15:58 UTC by Milan Crha
Modified: 2013-08-30 05:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
yet another backtrace (4.51 KB, text/plain)
2012-04-02 01:35 UTC, Mikhail
  Details
yet another backtrace after some time (6.79 KB, text/plain)
2012-04-02 01:36 UTC, Mikhail
  Details
yet another backtrace (4.52 KB, text/plain)
2012-04-02 01:36 UTC, Mikhail
  Details
ews patch (6.52 KB, patch)
2012-07-17 15:20 UTC, Milan Crha
committed Details | Review

Description Milan Crha 2012-03-29 15:58:39 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=807908

Evolution-ews hangs when saving changes to a folder whcih is not downloaded completely. Steps to reproduce:
a) have a large folder in your exchange account (thousands of messages)
b) enter the folder for the first time
c) let ews download few first messages from that folder
d) then cancel the operation and move to a different folder and back
e) you see few messages from the folder, and the operation of refreshing
   folder begun again. Cancel it.
f) mark few messages unread (those which were read)
g) move to other folder
Now there is a "Storing folder large..." operation running and shown at the bottom on the status bar. The operation doesn't seem to end. Corresponding backtrace (I do not know how, but the reporter managed to have there three threads waiting on the same operation, which I wasn't able to accomplish, though the operation of being stuck on storing folder works here too). Note the operations isn't fully dead, if I cancel it by pressing the red sign on the status bar belonging to it, then it is properly cancelled and other piled operations got its chance to continue.


Comment 1 Milan Crha 2012-03-30 07:02:19 UTC
I thought I can reproduce this yesterday, but I cannot today. If I wait for about 10 seconds then the "Storing folder large..." operation is finally finished and it continues to do its job, even the large folder is not downloaded completely. When I enter it again then it continues to download next bunch of messages. I'm still cancelling the "Refreshing folder larger..." operation, otherwise it would take as long as download of all messages in such folder would take. But that's just about current design of operations in evolution, not about evolution-ews at all.

I also tried to purge my local cache of ews messages from
  ~/.cache/evolution/mail/<ews-account-id>
to start from scratch, but it still works as expected. I do not know what made it fail yesterday.
Comment 2 Mikhail 2012-04-02 01:35:40 UTC
Created attachment 211097 [details]
yet another backtrace
Comment 3 Mikhail 2012-04-02 01:36:06 UTC
Created attachment 211098 [details]
yet another backtrace after some time
Comment 4 Mikhail 2012-04-02 01:36:39 UTC
Created attachment 211099 [details]
yet another backtrace
Comment 5 Milan Crha 2012-04-02 12:37:54 UTC
Thanks for the update. The first is waiting for e_ews_connection_update_items()
in one thread. The other threads seem to be idle. The second looks similarly,
only the function is shown in two threads. Finally the third does not do
anything with ews, it is waiting in Thread 3 on a response from your IMAP+
server.

I do not know why my steps from comment #0 failed to reproduce the issue again. There might be a hidden bug in my steps somewhere.
Comment 6 Milan Crha 2012-07-17 15:20:07 UTC
Created attachment 219028 [details] [review]
ews patch

for evolution-ews;

After a little chat with Dan Winship it turned out that only SoupSessionSync is thread safe, while SoupSessionAsync is not, thus any call to it should be done in ews_soup_thread(). This patch does just that.

What happened during my steps was that sometimes the soup_session_cancel_message() was called too early, thus its associated async_context was not removed from SoupSessionAsync::priv->idle_run_queue_sources, it was not there yet, which lead to inconsistent state in 'idle_run_queue_sources'. The next message queue did not invoke the queue run, because the 'idle_run_queue_sources' has the async_context already in - the previous remove failed.
Comment 7 Milan Crha 2012-07-17 16:00:57 UTC
Created commit 5a48790 in ews master (3.5.5+)
Created commit 9e7b5fd in ews gnome-3-4 (3.4.4+)
Comment 8 David Woodhouse 2012-07-17 19:52:52 UTC
(In reply to comment #6) 
> After a little chat with Dan Winship it turned out that only SoupSessionSync is
> thread safe, while SoupSessionAsync is not

I *still* consider that to be a libsoup bug. The number of hoops we have to jump through to work around it is horrible.

ISTR it was a *simple* fix, to correct the locking issues in SoupSessionAsync. But Dan just didn't want to apply it and claim that the code was thread-safe, in case there were other bugs. Or perhaps that's just my skewed interpretation…
Comment 9 Milan Crha 2012-07-18 09:21:32 UTC
I asked him on thread safety yesterday and he told me that Sync is thread safe, while Async is not. I agree it would be nice to have this fixed in libsoup, but if this is his decision, then we might do whatever is needed to have this working.
Comment 10 Mikhail 2012-07-19 02:31:55 UTC
I also think that this is a bug libsoup and it must be fixed. Where can I vote for it?
Comment 11 Matthew Barnes 2012-07-19 02:56:06 UTC
Bugzilla has no voting system and "me too" comments are generally ignored.

The way to vote for bugs is to provide patches for them.
Comment 12 David Woodhouse 2012-07-19 12:53:53 UTC
I filed a patch in bug 642573 to fix the locking bug in libsoup, and that seemed to make things work sanely. It was rejected because apparently there are more bugs which would also need to be fixed.
Comment 13 Milan Crha 2013-08-30 05:39:33 UTC
*** Bug 679241 has been marked as a duplicate of this bug. ***