Bug 67102 – Update Debugging on Mac OS X instructions for Safari 5.1/WebKit 2

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Website

[Daniel Bates]

Update the Mac OS X instructions on <http://www.webkit.org/building/debug.html> to explain how to debug Safari 5.1/WebKit 2.

See <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process>.

[Daniel Bates]

Created attachment 105458 [details]
Work-in-progress patch

Work-in-progress patch

I took the "attach to WebProcess" instructions on <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process> as inspiration for these updated instructions. In particular, I added WebProcess.app as the custom executable in the WebCore project and made Xcode wait for WebProcess.app to launch. Then ran run-safari to launch Safari. 

I am not so happy with this setup since it alternates between Xcode and the command line.

[Daniel Bates]

Created attachment 122285 [details]
Patch

[Daniel Bates]

Created attachment 122286 [details]
Screenshot of debug.html

[Daniel Bates]

Created attachment 122287 [details]
Screenshot of debug-mac-uiprocess.html

[Eric Seidel (no email)]

Comment on attachment 122285 [details]
Patch

This seems OK to me.  Certainly better than the very outdated instructions we have now.

[WebKit Review Bot]

Comment on attachment 122285 [details]
Patch

Clearing flags on attachment: 122285

Committed r105432: <http://trac.webkit.org/changeset/105432>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

(In reply to comment #1)
> Created an attachment (id=105458) [details]
> Work-in-progress patch
> 
> Work-in-progress patch
> 
> I took the "attach to WebProcess" instructions on <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process> as inspiration for these updated instructions. In particular, I added WebProcess.app as the custom executable in the WebCore project and made Xcode wait for WebProcess.app to launch. Then ran run-safari to launch Safari. 
> 
> I am not so happy with this setup since it alternates between Xcode and the command line.

There is a more streamlined way to do this now that bug 75444 is fixed. You can have create a scheme whose executable is WebProcess and pass it the command-line options to launch the client (the UI process). The arguments look something like
    "$(BUILT_PRODUCTS_DIR)/WebKit2.framework/WebKit2" -type webprocess -client-executable /Applications/Safari.app/Contents/MacOS/Safari
and the environment should contain
    DYLD_INSERT_LIBRARIES=$(BUILT_PRODUCTS_DIR)/WebProcessShim.dylib

[Eric Seidel (no email)]

(In reply to comment #8)
> (In reply to comment #1)
> > Created an attachment (id=105458) [details] [details]
> > Work-in-progress patch
> > 
> > Work-in-progress patch
> > 
> > I took the "attach to WebProcess" instructions on <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process> as inspiration for these updated instructions. In particular, I added WebProcess.app as the custom executable in the WebCore project and made Xcode wait for WebProcess.app to launch. Then ran run-safari to launch Safari. 
> > 
> > I am not so happy with this setup since it alternates between Xcode and the command line.
> 
> There is a more streamlined way to do this now that bug 75444 is fixed. You can have create a scheme whose executable is WebProcess and pass it the command-line options to launch the client (the UI process). The arguments look something like
>     "$(BUILT_PRODUCTS_DIR)/WebKit2.framework/WebKit2" -type webprocess -client-executable /Applications/Safari.app/Contents/MacOS/Safari
> and the environment should contain
>     DYLD_INSERT_LIBRARIES=$(BUILT_PRODUCTS_DIR)/WebProcessShim.dylib

Sounds useful.

Could we check in such a scheme into the repo?