Bug 101446 – [WK2][UNIX] Crash in WebKit::PluginProcessProxy::scanPlugin()

• Component: WebKit2
• Status: RESOLVED FIXED

[Chris Dumez]

I often get the following warning and crash in WebKit::PluginProcessProxy::scanPlugin() on my machine:

(process:12859): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa334b700 (LWP 12880)]
0x00007ffff7a178d3 in WebKit::PluginProcessProxy::scanPlugin (pluginPath=..., result=...) at /home/chris/Devel/WebKit/Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp:91
91	        while (*current++ != UChar('\n')) { }
(gdb) bt 25
#0  0x00007ffff7a178d3 in WebKit::PluginProcessProxy::scanPlugin (pluginPath=..., result=...) at /home/chris/Devel/WebKit/Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp:91
#1  0x00007ffff79d0f3c in WebKit::NetscapePluginModule::getPluginInfo (pluginPath=..., plugin=...) at /home/chris/Devel/WebKit/Source/WebKit2/Shared/Plugins/Netscape/x11/NetscapePluginModuleX11.cpp:131
#2  0x00007ffff7a1626f in WebKit::PluginInfoStore::getPluginInfo (pluginPath=..., plugin=...) at /home/chris/Devel/WebKit/Source/WebKit2/UIProcess/Plugins/unix/PluginInfoStoreUnix.cpp:101
#3  0x00007ffff78d158b in WebKit::PluginInfoStore::loadPlugin (plugins=..., pluginPath=...) at /home/chris/Devel/WebKit/Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp:118
#4  0x00007ffff78d14c0 in WebKit::PluginInfoStore::loadPluginsIfNecessary (this=0x4dc370) at /home/chris/Devel/WebKit/Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp:107
#5  0x00007ffff78d1601 in WebKit::PluginInfoStore::plugins (this=0x4dc370) at /home/chris/Devel/WebKit/Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp:130
#6  0x00007ffff78ab857 in WebKit::WebProcessProxy::handleGetPlugins (this=0x4f6fb0, requestID=1, refresh=false) at /home/chris/Devel/WebKit/Source/WebKit2/UIProcess/WebProcessProxy.cpp:347
#7  0x00007ffff78b7e29 in WTF::FunctionWrapper<void (WebKit::WebProcessProxy::*)(unsigned long, bool)>::operator() (this=0x7fff94000d80, c=0x4f6fb0, p1=1, p2=false)
    at /home/chris/Devel/WebKit/Source/WTF/wtf/Functional.h:214
#8  0x00007ffff78b7c62 in WTF::BoundFunctionImpl<WTF::FunctionWrapper<void (WebKit::WebProcessProxy::*)(unsigned long, bool)>, void (WebKit::WebProcessProxy*, unsigned long, bool)>::operator()() (
    this=0x7fff94000d70) at /home/chris/Devel/WebKit/Source/WTF/wtf/Functional.h:460
#9  0x00000000004662e4 in WTF::Function<void ()>::operator()() const (this=0x7fff940011f0) at /home/chris/Devel/WebKit/Source/WTF/wtf/Functional.h:614
#10 0x00007ffff79c75d1 in WorkQueue::performWork (this=0x7fff94000db0) at /home/chris/Devel/WebKit/Source/WebKit2/Platform/efl/WorkQueueEfl.cpp:83
#11 0x00007ffff79c7c4e in WorkQueue::workQueueThread (workQueue=0x7fff94000db0) at /home/chris/Devel/WebKit/Source/WebKit2/Platform/efl/WorkQueueEfl.cpp:178
#12 0x00007ffff398f95d in WTF::threadEntryPoint (contextData=0x7fff94000c10) at /home/chris/Devel/WebKit/Source/WTF/wtf/Threading.cpp:69
#13 0x000000000043799e in WTF::wtfThreadEntryPoint (param=0x7fff94000f40) at /home/chris/Devel/WebKit/Source/WTF/wtf/ThreadingPthreads.cpp:196
#14 0x00007ffff6f59e9a in start_thread (arg=0x7fffa334b700) at pthread_create.c:308
#15 0x00007ffff5d55cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

I'll investigate this and hopefully fix it.

[Chris Dumez]

Created attachment 172761 [details]
Patch

[Mikhail Pozdnyakov]

Comment on attachment 172761 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=172761&action=review

> Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp:75
> +    // If the dispositon of SIGCLD signal is set to SIG_IGN then

would be interesting to know why it was ignored

[Chris Dumez]

(In reply to comment #2)
> (From update of attachment 172761 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=172761&action=review
> 
> > Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp:75
> > +    // If the dispositon of SIGCLD signal is set to SIG_IGN then
> 
> would be interesting to know why it was ignored

The default disposition for SIGCLD signal *is* SIG_IGN.

I think I should move the disposition setting to the initialization function though to call it only once.

[Chris Dumez]

Created attachment 172768 [details]
Patch

Clarified the comment but kept the signal() instruction where it is since I cannot find a better place for it.

[Simon Hausmann]

Comment on attachment 172768 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=172768&action=review

> Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp:80
> +    signal(SIGCLD, SIG_DFL);

Shouldn't we be using sigaction() instead of signal()? AFAIK the latter is deprecated.

[Chris Dumez]

(In reply to comment #5)
> (From update of attachment 172768 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=172768&action=review
> 
> > Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp:80
> > +    signal(SIGCLD, SIG_DFL);
> 
> Shouldn't we be using sigaction() instead of signal()? AFAIK the latter is deprecated.

The signal man page seems to confirm your comment so I'll fix it before landing. Thanks!

[Chris Dumez]

Created attachment 172775 [details]
Patch

Use sigaction() instead of signal() since signal() is deprecated.

[WebKit Review Bot]

Comment on attachment 172775 [details]
Patch

Clearing flags on attachment: 172775

Committed r133755: <http://trac.webkit.org/changeset/133755>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.