Bug 101446 - [WK2][UNIX] Crash in WebKit::PluginProcessProxy::scanPlugin()
Summary: [WK2][UNIX] Crash in WebKit::PluginProcessProxy::scanPlugin()
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords:
Depends on: 108371
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-07 04:09 PST by Chris Dumez
Modified: 2013-01-30 13:04 PST (History)
7 users (show)

See Also:


Attachments
Patch (3.37 KB, patch)
2012-11-07 05:01 PST, Chris Dumez
kenneth: review+
Details | Formatted Diff | Diff
Patch (3.35 KB, patch)
2012-11-07 05:29 PST, Chris Dumez
kenneth: review+
cdumez: commit-queue-
Details | Formatted Diff | Diff
Patch (3.51 KB, patch)
2012-11-07 05:47 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2012-11-07 04:09:27 PST
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.
Comment 1 Chris Dumez 2012-11-07 05:01:03 PST
Created attachment 172761 [details]
Patch
Comment 2 Mikhail Pozdnyakov 2012-11-07 05:15:00 PST
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
Comment 3 Chris Dumez 2012-11-07 05:19:22 PST
(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.
Comment 4 Chris Dumez 2012-11-07 05:29:45 PST
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.
Comment 5 Simon Hausmann 2012-11-07 05:34:18 PST
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.
Comment 6 Chris Dumez 2012-11-07 05:36:36 PST
(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!
Comment 7 Chris Dumez 2012-11-07 05:47:34 PST
Created attachment 172775 [details]
Patch

Use sigaction() instead of signal() since signal() is deprecated.
Comment 8 WebKit Review Bot 2012-11-07 06:56:15 PST
Comment on attachment 172775 [details]
Patch

Clearing flags on attachment: 172775

Committed r133755: <http://trac.webkit.org/changeset/133755>
Comment 9 WebKit Review Bot 2012-11-07 06:56:19 PST
All reviewed patches have been landed.  Closing bug.