[9fans] ratrace problem; debuggers welcome

[9fans] ratrace problem; debuggers welcome

[ron minnich]

there's a race in ratrace: programs can escape. The reason is that the
parent forks a child and writes stop to its ctl file. But the child
can run any number of system calls -- even to completion -- before the
parent writes that stop command. I'm seeing this on arm.

The fix is simple, in the child, write "hang" to proc/getpid()/ctl.

Simple, right? Well, not so simple.

In the old ratrace, I can (e.g.)
ratrace -c /bin/rc
and I will trace all the rcs and their kids, foever and ever.

In the ratrace with the child process writing hang to its own ctl,
eventually, ratrace goes away. Not Broken, just gone, and the
symptom is that the first command in the traced rc is traced, but no
further commands are.

Anyway, if somebody is up for debugging fun, I can send you the
modified ratrace and you can see what I might have gotten wrong.

thanks

ron

Re: [9fans] ratrace problem; debuggers welcome

[erik quanstrom]

On Sun Feb 13 19:34:25 EST 2011, rminnich@gmail.com wrote:
> there's a race in ratrace: programs can escape. The reason is that the
> parent forks a child and writes stop to its ctl file. But the child
> can run any number of system calls -- even to completion -- before the
> parent writes that stop command. I'm seeing this on arm.

at least from the source i have, writing to p->hang after
the fork isn't going to do anything.  p->hang is only consulted
in sysexec.  i think you need to add the same test in sysfork.

i did notice a similar race in ratrace the other week when
i was using it to test some ata raw io.  it was an easy way
to audit a command sequence.

it turns out that printing "." instead of the character for
non-ascii is unworkable for some things.  my quick hack
was to change fmtrwdata to look (something) like this.
the nil ptr case may still be difficult to parse.

static void
fmtrwdata(Fmt* f, char* a, int n, char* suffix)
{
	int i, j, hex;

	if(a == nil){
		fmtprint(f, "%#p/%s", (uintptr)0, suffix);
		return;
	}
	validaddr((ulong)a, n, 0);
	hex = 0;
	for(i = 0; i < n; i++)
		if(a[i] < 0x20 || (uchar)a[i] > 0x7f){
			hex = 1;
			break;
		}
	if(hex)
		fmtprint(f, " %#p/.*H%s", a, n, a, suffix);
	else
		fmtprint(f, " %#p/\"%.*s\"%s", a, n, a, suffix
}

- erik

Re: [9fans] ratrace problem; debuggers welcome

[ron minnich]

On Sun, Feb 13, 2011 at 7:50 PM, erik quanstrom <quanstro@quanstro.net> wrote:

> at least from the source i have, writing to p->hang after
> the fork isn't going to do anything.  p->hang is only consulted
> in sysexec.  i think you need to add the same test in sysfork.

It is only supposed to be consulted in sysexec. Hang just means that
the next exec will result in a stop, not the fork. You really only
want to look for the hang when exec is called. In fact the parent can
call exec -- even before a fork -- and the child will halt in the
exec. Very handy.

> it turns out that printing "." instead of the character for
> non-ascii is unworkable for some things.

I made a bad mistake there. Let's pick some sort of standard format
and go with it.

Here's my suggestion. Non-printable characters will be printed as \xx
where xx is the hex code. '\' is considered a non-printable character
because we don't want to get confused. Does that work for people?

ron

Re: [9fans] ratrace problem; debuggers welcome

[erik quanstrom]

> > at least from the source i have, writing to p->hang after
> > the fork isn't going to do anything.  p->hang is only consulted
> > in sysexec.  i think you need to add the same test in sysfork.
>
> It is only supposed to be consulted in sysexec. Hang just means that
> the next exec will result in a stop, not the fork. You really only
> want to look for the hang when exec is called. In fact the parent can
> call exec -- even before a fork -- and the child will halt in the
> exec. Very handy.

i thought traced programs were supposed to hang on every sys call.
and i think that Proc->procctl is not copied into the forked
process.  what am i missing?

> > it turns out that printing "." instead of the character for
> > non-ascii is unworkable for some things.
>
> I made a bad mistake there. Let's pick some sort of standard format
> and go with it.
>
> Here's my suggestion. Non-printable characters will be printed as \xx
> where xx is the hex code. '\' is considered a non-printable character
> because we don't want to get confused. Does that work for people?

that doesn't really work for me.  either the kernel should always print
as hex, or the decision should be made for the whole string.  the \x
notation requires that any \x be excaped.  you potentially need to escape
both " and \.  it's a difficult and non-standard quoting scheme for plan 9.
if you think the kernel really needs to be making a decision based on
utf-8/not utf-8 (not 7-bit ascii!), i would think the most standard way
of formatting this would be nil, %.*q or %.*H.

- erik

[9fans] Formats %H, $<, %[ (Was re. ratrace problem; debuggers welcome)

[Joel C. Salomon]

On 02/14/2011 01:03 AM, erik quanstrom wrote:
> that doesn't really work for me.  either the kernel should always print
> as hex, or the decision should be made for the whole string.  the \x
> notation requires that any \x be excaped.  you potentially need to escape
> both " and \.  it's a difficult and non-standard quoting scheme for plan 9.
> if you think the kernel really needs to be making a decision based on
> utf-8/not utf-8 (not 7-bit ascii!), i would think the most standard way
> of formatting this would be nil, %.*q or %.*H.

I remembered reading of, and using, the %q format, but %H is new to me.
 The web version of print(2) doesn’t describe it, so I went to the source.

In libc.h I found
	#pragma varargck	type	"<"	void*
	#pragma varargck	type	"["	void*
	#pragma varargck	type	"H"	void*
	#pragma varargck	type	"lH"	void*
but none of these are in the knownfmt[] array in sys/src/libc/fmt/fmt.c
and I don’t see where fmtinstall() is called for them.

What do these formats do?

--Joel

Re: [9fans] Formats %H, $<, %[ (Was re. ratrace problem; debuggers welcome)

[erik quanstrom]

> I remembered reading of, and using, the %q format, but %H is new to me.
>  The web version of print(2) doesn’t describe it, so I went to the source.
>
> In libc.h I found
> 	#pragma varargck	type	"<"	void*
> 	#pragma varargck	type	"["	void*
> 	#pragma varargck	type	"H"	void*
> 	#pragma varargck	type	"lH"	void*
> but none of these are in the knownfmt[] array in sys/src/libc/fmt/fmt.c
> and I don’t see where fmtinstall() is called for them.
>
> What do these formats do?

encodefmt(2).

- erik