GNOME Bugzilla – Bug 691399
Deadlock with sync session under soup_session_abort() called from the main thread
Last modified: 2013-02-06 13:30:24 UTC
I'm on libsoup's git master at commit 1ac2f9dedf6333438698 and I get this freeze in evolution-calendar-factory. Note this is a SoupSessionSync, thus I guess I should see its activity in other threads.
+ Trace 231361
Thread 1 (Thread 0x7f3fb2262980 (LWP 21269))
Is this reliable/sporadic/one-time-only? I just tried reproducing but couldn't.
I tried with get.c and I cannot too, but in eds it crashes. It seems to me that it's something with GLib and its signal disconnection - see the source_changed_cb(). It seems like the backend is already disposed, but it disconnects from that signal in that time... I'm investigating further.
Err, some race condition in eds, the backend was freed inside the crashing function, thus this lead to use-after-free. I did not notice this with stable GLib/GIO, thus maybe it's caused by delays and thread schedule or something, but when I add and remove a reference in the source_changed_cb() to the backend, then it doesn't crash. In any way, this is not a libsoup bug. I'm sorry for a false alarm.
Hrm, it wasn't it, I get the freeze in soup_session_abort() on the property set even with the backend being reffed. The session has one pending item. I'll investigate further and if I find anything on the libsoup side, then I'll update the bug.
it's possible some message has gotten "stranded" somehow, so that it will never complete... would want to see what its SoupMessageQueueItem looked like...
Created attachment 233113 [details] test.c I'm reopening this. Here's a reproducer, just simple libsoup. The first line contains a command to compile and run it. The deadlock looks like: > waiting one second in main idle > about to send the message at a thread > done with wait one second in main idle, setting proxy to NULL > finished the message send at a thread I see this with libsoup-2.40.2-1.fc18.x86_64, thus I'm changing the version as well.
Just verified that the line > g_object_set (session, "proxy-uri", NULL, NULL); in the test.c can be replaced with > soup_session_abort (session); and it'll deadlock too.
I had to modify the test case to decrease the timeout each round; for me, the deadlock tended to happen at around .5 seconds. Fixed in master. For 2.40, I believe that adding "g_cond_broadcast (priv->cond);" after the soup_session_unqueue_item() call in soup-session-sync.c's process_queue_item() should fix it. Can you try that? (I'm thinking I'll put out a 2.40 release along with the 2.41 release next week.)
OK, I changed it to: g_cond_broadcast (&priv->cond); and it helped, it doesn't freeze anymore (I left it running for several cycles and it didn't freeze, while it would freeze in the first or max the ~5th cycle without the change).
belatedly closing; this is fixed in master and 2.40.3