renderer debugging script

[Steve Kobes]

I added a small script in Tools/Scripts/debug-renderer that you may find useful.  It starts chrome or content_shell and attaches gdb in the same terminal.  This is nice for debugging layout tests, or other situations where you want the renderer to wait for the debugger.

$ alias rdbg=third_party/WebKit/Tools/Scripts/debug-renderer

$ rdbg out/Debug/content_shell --dump-render-tree about:blank

[...]

Debugging renderer, use 'signal SIGUSR1' to run.

[...]

(gdb) signal SIGUSR1

[...]

Content-Type: text/plain

layer at (0,0) size 800x600

  RenderView at (0,0) size 800x600

layer at (0,0) size 800x600

  RenderBlock {HTML} at (0,0) size 800x600

    RenderBody {BODY} at (8,8) size 784x584

[...]

Q: Why not --single-process?

A: --single-process seems to crash a lot, and (I've heard) isn't really supported.

Q: Why not --renderer-cmd-prefix='xterm -e gdb --args'?

A: This opens a separate terminal, and forces you to use xterm, which is annoying (e.g., poor clipboard support).

Q: Why not --renderer-cmd-prefix='gnome-terminal -x gdb --args'?

A: You'd think this would work.  Sadly it does not work (fires assertion in sys_info_linux.cc).

Q: Why not run as a background process with --renderer-startup-dialog, then find the renderer pid in the output and attach gdb to it?

A: That's what the script automates. :)

[Morten Stenshorne]

Steve Kobes <sko...@chromium.org> writes:

> Q: Why not --single-process?
> A: --single-process seems to crash a lot, and (I've heard) isn't really supported.

I use --single-process (with content_shell) all the time without
trouble. It only crashes when it should (assertion failure, actual
crashes). :)

I run gdb inside emacs. Works great, except for an insane startup time
(3 minutes or more) every time I have to (re-)start gdb (so I try to
avoid that, when possible). Starting a rebuilt content_shell is
reasonably fast (30 seconds or so). Starting an unchanged content_shell
is instant-ish.

Wait... actually, sometimes it *does* crash during startup (don't know
it it has anything to do with --single-process), for no good reason, but
that happens about twice a month or so (normally something related to
getenv(), I think), so I can live with it.

Does anyone know more about --single-process not being supported?

--
---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ http://www.opera.com/ -----------------

[Stefan Zager]

On Tue Jan 13 2015 at 1:54:03 AM Morten Stenshorne <mste...@opera.com> wrote:

I run gdb inside emacs.

Hooray!  There are dozens of us!  Dozens! 

[Dirk Pranke]

On Tue, Jan 13, 2015 at 1:53 AM, Morten Stenshorne <mste...@opera.com> wrote:

Steve Kobes <sko...@chromium.org> writes:

> Q: Why not --single-process?
> A: --single-process seems to crash a lot, and (I've heard) isn't really supported.

I use --single-process (with content_shell) all the time without
trouble. It only crashes when it should (assertion failure, actual
crashes). :)

I run gdb inside emacs. Works great, except for an insane startup time
(3 minutes or more) every time I have to (re-)start gdb (so I try to
avoid that, when possible). Starting a rebuilt content_shell is
reasonably fast (30 seconds or so). Starting an unchanged content_shell
is instant-ish.

Wait... actually, sometimes it *does* crash during startup (don't know
it it has anything to do with --single-process), for no good reason, but
that happens about twice a month or so (normally something related to
getenv(), I think), so I can live with it.

Does anyone know more about --single-process not being supported?

--single-process is definitely "kinda" supported and won't be going away any time soon because, IIUC, the Android WebView implementation of Chrome needs it. 

However, I think there's little to no effort going into making it work better, and there was definitely at some point a largish faction of Chrome that thought that we should not spend any effort to do so, because it was bad that single process worked at all. I'm not sure how strong that thinking currently is.

-- Dirk