Bug 56116

Summary: [Qt][WK2] Need a way to debug the web process after the UI process dies
Product: WebKit Reporter: Balazs Kelemen <kbalazs>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, commit-queue
Priority: P5 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
Attachments:
Description Flags
Patch none

Description Balazs Kelemen 2011-03-10 10:05:47 PST
We disallow the web process to live out it's parent dead: prctl(PR_SET_PDEATHSIG, SIGKILL)
For developers it could be useful to be able to debug a web process that's parent has already died.
Another debugging issue with the current setup is that when one attach to the web process
via 'set-follow-fork-mode child' and press ^C to interrupt the web process it terminates immediately.
Comment 1 Balazs Kelemen 2011-03-10 10:17:26 PST
Created attachment 85343 [details]
Patch
Comment 2 Benjamin Poulain 2011-03-14 03:35:43 PDT
Out of curiosity, what was the use case?
Comment 3 Balazs Kelemen 2011-03-14 10:45:49 PDT
(In reply to comment #2)
> Out of curiosity, what was the use case?

(gdb) set follow-fork-mode child
(gdb) r
Starting program: /home/balazs/master_clean/WebKitBuild/Debug/bin/MiniBrowser 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffebf45710 (LWP 28471)]
[New Thread 0x7fffeb744710 (LWP 28472)]
[New process 28473]
[Thread debugging using libthread_db enabled]
process 28473 is executing new program: /home/balazs/master_clean/WebKitBuild/Debug/bin/QtWebProcess
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffebf45710 (LWP 28571)]
[New Thread 0x7fffea7f2710 (LWP 28572)]
^C[Thread 0x7fffea7f2710 (LWP 28572) exited]
[Thread 0x7fffebf45710 (LWP 28571) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.

With the patch via ^C the debugger can normally interrupt execution.
Comment 4 Benjamin Poulain 2011-03-14 11:25:07 PDT
I understand that can happen, but what is the use case for debugging the Web process without having the UI process? It is not like anything will happen and the memory dump seems just as useful.
Comment 5 Balazs Kelemen 2011-03-14 16:40:19 PDT
(In reply to comment #4)
> I understand that can happen, but what is the use case for debugging the Web process without having the UI process? It is not like anything will happen and the memory dump seems just as useful.

Oh, I see. Yes, maybe this possibility is not really valuable
but it is really annoying that one cannot interrupt the execution 
while debugging. It's not clear to me why the UI process exiting
in that case, maybe gdb is not compatible with our usage of prctl.
The target of the patch is to work around this behavior.
Comment 6 Balazs Kelemen 2011-03-18 10:59:05 PDT
ping
Comment 7 Benjamin Poulain 2011-03-18 11:51:45 PDT
Comment on attachment 85343 [details]
Patch

Ok, read your comments again, and I finally understand why I don't have the problem.
I only gdb the QtWebProcess, by attaching to it. Your use case make sense, I did not fully understand it.

Please document QT_WEBKIT_KEEP_ALIVE_WEB_PROCESS on the Wiki.
Comment 8 WebKit Commit Bot 2011-03-18 13:55:17 PDT
The commit-queue encountered the following flaky tests while processing attachment 85343 [details]:

webarchive/test-link-rel-icon.html bug 56663 (author: ddkilzer@webkit.org)
The commit-queue is continuing to process your patch.
Comment 9 WebKit Commit Bot 2011-03-18 13:57:28 PDT
Comment on attachment 85343 [details]
Patch

Clearing flags on attachment: 85343

Committed r81507: <http://trac.webkit.org/changeset/81507>
Comment 10 WebKit Commit Bot 2011-03-18 13:57:33 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 WebKit Commit Bot 2011-03-18 15:25:04 PDT
The commit-queue encountered the following flaky tests while processing attachment 85343 [details]:

webarchive/test-link-rel-icon.html bug 56663 (author: ddkilzer@webkit.org)
The commit-queue is continuing to process your patch.