Debugging child processes, -f versus -p versus -g

Kyle Huey me at kylehuey.com
Wed Apr 6 17:09:03 UTC 2016


On Wed, Apr 6, 2016 at 9:55 AM, Benjamin Smedberg <benjamin at smedbergs.us>
wrote:

> I am trying to debug some Firefox plugin tests which have a process
> hierarchy, and I don't quite understand how debugging multiple processes in
> a recording works, and in particular -f and -p.
>
> First: when you're debugging a replay, do you have access to all the
> processes in one debugging session? Or is it necessary to debug one process
> at a time and then use event-numbers to synchronize? If they are all one
> debugging session, do breakpoints apply to all processes or just one?
>
> Second: what processes do -p and -f attach to by default? Is the primary
> difference between them that -f <PID> attaches to the "parent" of PID -p
> attaches to the child of PID, but at the same point in time? Or am I
> totally misunderstanding?
>

>From gdb, you only have access to one process at a time. rr does in fact
replay the entire "constellation" of processes that were recorded, but gdb
is gdb.

IIRC (and I am going from memory here), if you specify -g <event number>
alone, by default we will attach gdb to whatever process <event number> is
in. If you specify -f <PID> or -p <PID> alone, we'll attach to process
<PID>. And if you specify -g <event number> with -f <PID> or -p <PID>,
we'll attach to process <PID> at the first event in that process after
<event number>, even if <event number> is in a different process.

The only difference between -f and -p is whether or not we wait for the
process to exec. If you specify -p <PID>, and <PID> never execs, we'll
never attach gdb.

The best way to debug multiprocess firefox is to start a separate rr replay
for each process you want to debug.  You can "synchronize" the world by
using 'when' in gdb to get the global event number and comparing them.  I
don't think we have the ability to, from within gdb, break at a given event
number, but it's something I've wanted to add before.

- Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20160406/eeb6c2a9/attachment.html>


More information about the rr-dev mailing list