Bug 164916 – [GTK] Crash in IPC::GSocketMonitor::start

• Component: WebKitGTK
• Status: RESOLVED INVALID

[Michael Catanzaro]

Web process crash in IPC::GSocketMonitor::start, we try to g_source_attach on a NULL GSource*:

Truncated backtrace:
Thread no. 1 (6 frames)
 #0 g_source_attach at gmain.c:1163
 #1 IPC::GSocketMonitor::start(_GSocket*, GIOCondition, WTF::RunLoop&, std::function<int (GIOCondition)>&&) at /usr/src/debug/webkitgtk-2.12.3/Source/WebKit2/Platform/IPC/glib/GSocketMonitor.cpp:54
 #2 IPC::Connection::open at /usr/src/debug/webkitgtk-2.12.3/Source/WebKit2/Platform/IPC/unix/ConnectionUnix.cpp:394
 #3 WebKit::ChildProcess::initialize at /usr/src/debug/webkitgtk-2.12.3/Source/WebKit2/Shared/ChildProcess.cpp:73
 #4 WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain> at /usr/src/debug/webkitgtk-2.12.3/Source/WebKit2/Shared/unix/ChildProcessMain.h:60
 #6 _start

Full backtrace downstream.

[Michael Catanzaro]

Bug tracker system says "probably fixed in 2.12.4" but I don't know if I believe it or not, there's only 7 reports of this total.

[Carlos Garcia Campos]

This is super weird, I would like see the WebKitWebProcess cmdline. Because what happens is that the connectionIdentifier is 0 in ChildProcessInitializationParameters.

#4  0x00007f95ea114ab4 in WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain> (argc=<optimized out>, argv=0x7ffc494af528) at /usr/src/debug/webkitgtk-2.12.3/Source/WebKit2/Shared/unix/ChildProcessMain.h:60
        childMain = {<WebKit::ChildProcessMainBase> = {_vptr.ChildProcessMainBase = 0x7f95ebcc95b8 <vtable for WebKit::WebProcessMain+16>, m_parameters = {uiProcessName = {m_impl = {m_ptr = 0x0}}, clientIdentifier = {m_impl = {m_ptr = 0x0}}, connectionIdentifier = 0, extraInitializationData = {m_impl = {static m_maxLoad = <optimized out>, static m_minLoad = <optimized out>, m_table = 0x0, m_tableSize = 0, m_tableSizeMask = 0, m_keyCount = 0, m_deletedCount = 0}}}}, <No data fields>}

connectionIdentifier = 0. Than can only happen if argc < 2 or atoi returns 0, and:

0x00007f95dfd78731 in __libc_start_main (main=0x56518f624c20 <main(int, char**)>, argc=2, argv=0x7ffc494af528, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc494af518) at ../csu/libc-start.c:289

argc = 2, as expected. So, for some reason atoi is returning 0, that's because 0 was passed or because it failed to convert I guess, we should probably use strtol instead, but we assumed that atoid would never fail because the web process is only spawned by the UI process. The other option could be that the UI process failed to created the sockets, but that would have crashed the UI process even before trying to spawn the web process, because socketpair is called inside a RELEASE_ASSERT. So, I have no idea what's going on here, but it's very weird.

[Carlos Garcia Campos]

Ok, I see the problem now:

Core was generated by `./WebKitWebProcess --help'.

This is definitely not our fault, WebKitWebProcess is not a process expected to be manually run by a user, that's why it's not in /usr/bin, but in libexec. All WebKit processes should *only* be spawned by the UI process.

[Michael Catanzaro]

(In reply to comment #3)
> Ok, I see the problem now:
> 
> Core was generated by `./WebKitWebProcess --help'.

TBH it's rare that cmdline is useful for a bug report, that's why I never copy it here. Excellent. :p