On Tue, 2010-05-25 at 11:13 +0200, Mark Phalan wrote:
> On Mon, 2010-05-24 at 15:16 -0400, Chad Mynhier wrote:
> > On Mon, May 24, 2010 at 8:56 AM, Mark Phalan <mark.pha...@sun.com> wrote:
> > > On Mon, 2010-05-24 at 13:42 +0200, Mark Phalan wrote:
> > >> On Tue, 2010-05-18 at 17:28 -0400, Angelo Rajadurai wrote:
> > >> >
> > >> > The way to fix it is to set strsize
> > >> >
> > >> > #pragma D option strsize=1024 // make sure your string can fit in!
> > >> >
> > >>
> > >> Thanks for the idea but it doesn't seem to make any difference even if I
> > >> increase strsize up to 2097152 (above which I get drops).
> > >> The size of the string is just 5 characters "TEST" + "@".
> > >>
> > >> I'll file a bug.
> > >
> > >
> > > 6955097 "out of scratch space in action" error with small amounts of
> > > data
> > >
> >
> > I don't think this is a bug in DTrace, I think this is just an
> > off-by-one error in your original code. Try adding 1 to data.length.
>
> In the simple example I included the string is NULL-terminated. This
> isn't the case in reality. strings are represented by a pointer (data)
> and a string length (length).
>
> Anyway, I changed the C to look like this:
>
> int main() {
> my_data data;
>
> data.length = strlen("TEST") + 1;
> data.data = "TEST";
>
> SIMPLE_START(&data);
> }
>
> and I see exactly the same error.
>
> >
> > Even though "string" is a separate type in DTrace, a string is still
> > just stored as a null-terminated sequence of characters. stringof()
> > isn't doing anything to null-terminate what you give it, it's just
> > assuming that you're giving it something that's null-terminated. In
> > this case, it appears that there's enough garbage after the copied-in
> > string to ...
>
> I thought that stringof() was being clever. I see this example:
>
> "To print only as much of the string as the caller intended, use the
> copyin() subroutine, which takes a size as its second argument:
>
>
> syscall::write:entry
> {
> printf("%s", stringof(copyin(arg1, arg2)));
> }"
>
> from: http://docs.sun.com/app/docs/doc/817-6223/chp-user?a=view
>
> which seems to imply that stringof() should NULL-terminate.
>
> Is the above example incorrect?
>
> >
> > Oh. I know what's happening. Because there's no null-termination on
> > the string, strjoin() actually ends up generating the garbage that
> > makes the copied-in string appear infinitely long.
> >
> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> > | T | E | S | T | @ | T | E | S | T | @ | T | E | S | T | ...
> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> > ^ ^
> > | |
> > A B
> >
> > strjoin() is copying from pointer A to pointer B. Pointer A never
> > hits a '\0', you just end up running out of scratch space.
>
Another data point. This works fine:
data_string = lltostr(strlen(stringof(copyin((uintptr_t)(*((uint32_t
*)
copyin((uintptr_t)&P->data, sizeof (uint32_t)))), *((uint32_t *)
copyin((uintptr_t)&P->length, sizeof (uint32_t))) -1))));
i.e. strlen seems to work fine on the result of stringof() and returns
"3".
-M
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
