Bug 107439 – [Soup] Random thread crashes

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Sergio Villar Senin]

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Invalid argument.  Aborting.

Program received signal SIGABRT, Aborted.
0x00007ffff016b475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff016b475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff016e6f0 in *__GI_abort () at abort.c:92
#2  0x00007ffff0db020b in g_thread_abort (status=22, function=0x7ffff0e3a52f "pthread_mutex_lock") at gthread-posix.c:76
#3  0x00007ffff0db0397 in g_mutex_lock (mutex=0x21c1730) at gthread-posix.c:211
#4  0x00007ffff0d60d56 in g_main_context_find_source_by_user_data (context=0x21c1730, user_data=0x77b1a0) at gmain.c:2050
#5  0x00007ffff41feefe in soup_session_real_kick_queue (session=0x77b180) at soup-session.c:2123
#6  0x00007ffff41fefbc in soup_session_kick_queue (session=0x77b180) at soup-session.c:2141
#7  0x00007ffff4201d20 in soup_session_send_async (session=0x77b180, msg=0x2646d90, cancellable=0x227be40, callback=0x7ffff41f641c <http_input_stream_ready_cb>, user_data=0x22de0e0) at soup-session.c:3909
#8  0x00007ffff41f65b9 in soup_request_http_send_async (request=0x22f25e0, cancellable=0x227be40, callback=0x7ffff5e11c70 <WebCore::sendRequestCallback(_GObject*, _GAsyncResult*, void*)>, user_data=0x7fff8853d768) at soup-request-http.c:143
#9  0x00007ffff41f5170 in soup_request_send_async (request=0x22f25e0, cancellable=0x227be40, callback=0x7ffff5e11c70 <WebCore::sendRequestCallback(_GObject*, _GAsyncResult*, void*)>, user_data=0x7fff8853d768) at soup-request.c:244
#10 0x00007ffff5e11ba4 in WebCore::ResourceHandle::start(WebCore::NetworkingContext*) () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0
#11 0x00007ffff5e02931 in WebCore::ResourceHandle::create(WebCore::NetworkingContext*, WebCore::ResourceRequest const&, WebCore::ResourceHandleClient*, bool, bool) () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0
#12 0x00007ffff561ef6c in WebCore::ResourceLoader::start() () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0
#13 0x00007ffff5623f8a in WebCore::ResourceLoadScheduler::servePendingRequests(WebCore::ResourceLoadScheduler::HostInformation*, WebCore::ResourceLoadPriority) () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0
#14 0x00007ffff56244ae in WebCore::ResourceLoadScheduler::scheduleSubresourceLoad(WebCore::Frame*, WebCore::CachedResource*, WebCore::ResourceRequest const&, WebCore::ResourceLoadPriority, WebCore::ResourceLoaderOptions const&) () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0
#15 0x00007ffff55b921c in WebCore::CachedResource::load(WebCore::CachedResourceLoader*, WebCore::ResourceLoaderOptions const&) () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0
#16 0x00007ffff55bedd9 in WebCore::CachedResourceLoader::requestResource(WebCore::CachedResource::Type, WebCore::CachedResourceRequest&) () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0
#17 0x00007ffff55c0658 in WebCore::CachedResourceLoader::requestCSSStyleSheet(WebCore::CachedResourceRequest&) () from ~/opt/gnome3/lib64/libwebkitgtk-3.0.so.0

[Sergio Villar Senin]

BTW I can consistently reproduce it just by trying to log in http://twitter.com

[Sergio Villar Senin]

OK, so I've just realized that it only happens if I'm using the patch for bug 107432.

Dan, is there any problem on mixing async and sync calls for accessing a given stream? (that patch is synchronously closing a stream that have been read asynchronously).

[Dan Winship]

It's supposed to work... and if it was going to fail, I wouldn't expect it to fail like this, which looks like a refcounting problem or something... double-check that there isn't something else wrong in the sync close patch?

[Sergio Villar Senin]

(In reply to comment #3)
> It's supposed to work... and if it was going to fail, I wouldn't expect it to fail like this, which looks like a refcounting problem or something... double-check that there isn't something else wrong in the sync close patch?

I got some slightly different backtraces, most of them when loading resources synchronously, which requires some push/pop_thread magic. Could it be related to that?

[Justin Schuh]

Created attachment 183872 [details]
Patch

[Justin Schuh]

Comment on attachment 183872 [details]
Patch

Please ignore. I fat-fingered a bug number.

[Sergio Villar Senin]

OK I found what's going on. So there was a mixture of things. There is a bug in libsoup which was somehow uncovered by the patch for https://bugs.webkit.org/show_bug.cgi?id=107432.

But I think there is also a bug in our network stack for synchronous requests. We directly stop the inner main loop we create to emulate synchronous requests in didFinishLoading() but we do not check if we have pending sources in that context we create.

[Sergio Villar Senin]

Created attachment 184001 [details]
Patch

[Martin Robinson]

Comment on attachment 184001 [details]
Patch

Okay. This seems reasonable.

[Sergio Villar Senin]

Comment on attachment 184001 [details]
Patch

Clearing flags on attachment: 184001

Committed r140445: <http://trac.webkit.org/changeset/140445>

[Sergio Villar Senin]

All reviewed patches have been landed.  Closing bug.