[Webkit-unassigned] [Bug 112729] [GTK] Web Process crash when the UI process finishes too early

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=112729





--- Comment #7 from Lauro Moura Maranhao Neto <lauro.neto at openbossa.org>  2013-04-08 11:57:03 PST ---
(In reply to comment #6)
> (In reply to comment #4)
> > Also, I've tested this patch with the Nix test I posted on bug #85066 [1] and it works almost fine. Sometimes the Connection's WorkQueue would lock in infinite poll calls when doing series of instant crash/respawn of the WebProcess. I think this happens because ProcessLauncherGtk.cpp::childFinishedFunction can close the socket in another thread while it's being polled by the Connection's WorkQueue.
> 
> Yes, I said that part of the patch written for the other bug was already solved by this patch. This fixes the case of the ui process returning too early, but it probably needs changes in the process launcher to fix the other bug. 

Ok.


> > From the close(2) man page:
> > "It  is  probably  unwise to close file descriptors while they may be in use by system calls in other threads in the same process.  Since a file descriptor may be reused, there  are  some  obscure race conditions that may cause unintended side effects."
> > 
> > Should I open a separate bug for this? I'll try to trigger this condition in WebKitGtk+ using a modified version of WK2's MouseMoveAfterCrash.cpp.
> 
> If the problem is the same than the mouse move after crash test issue, leave the other bug and make it depende on this one. 

Even after fixing the bad file descriptor/lockup issues the mouse move test fails (Both GTK and Nix). So I'll open a new bug about the process launcher fixes and make the mouse move one depend on it. Thanks!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.