Bug 164916 - [GTK] Crash in IPC::GSocketMonitor::start
Summary: [GTK] Crash in IPC::GSocketMonitor::start
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-18 05:01 PST by Michael Catanzaro
Modified: 2016-11-30 09:35 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2016-11-18 05:01:34 PST
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.
Comment 1 Michael Catanzaro 2016-11-18 05:02:55 PST
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.
Comment 2 Carlos Garcia Campos 2016-11-30 04:16:31 PST
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.
Comment 3 Carlos Garcia Campos 2016-11-30 05:29:25 PST
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.
Comment 4 Michael Catanzaro 2016-11-30 09:35:34 PST
(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