[Toybox] one last find thing...

[enh]

On Sat, Jun 15, 2019 at 4:30 PM Rob Landley <rob at landley.net> wrote:
>
> On 6/14/19 3:57 PM, enh wrote:
> > (i haven't had time to investigate, and i don't have any useful test
> > case other than "some timezone testing fails to run on emulators in
> > the cloud, in a way that gives me no useful failure", but i'm getting
>
> Does it _reliably_ fail to run?

seems like it. i've kicked off another build "just in case" every day,
but it looks like the same failure (modulo the fact that i don't have
any real detail), and _other_ changes are going through fine.

> > increasingly convinced that the DIRTREE_STATELESS patch does break
> > something, and it's not just an infrastructure issue... i wouldn't
> > normally send such a useless bug report, but i've failed to get to
> > this in 3 days, and i'm not likely to for at least 3 more at this
> > point, so i thought i'd at least mention it...)
>
> This isn't going to break anything, is it?
>
> -      openat(dirtree_parentfd(new), new->name, O_CLOEXEC), flags);
> +      openat(dirtree_parentfd(new), new->name, O_PATH|O_CLOEXEC), flags);

(one thing that occurred to me over the weekend is that it anywhere we
use O_PATH might break macOS, since there is no O_PATH there. but the
failures in question are on Android. [the builds in question don't
contain a new host prebuilt.])

> Moving struct st earlier within struct dirtree could reveal an existing bug, but
> the bug itself would be elsewhere.
>
> If strcpy(s, "") with only a single byte allocated to s[] wrote past the end of
> it, we'd have bigger problems...
>
> I'm not spotting what else could be the culprit? (And with a _timezone_
> test...?)

i don't think that's relevant. it's just a test that (afaict) runs on
the host and calls commands on the device via adb. (don't ask... i
can't defend the "host-side tests" stuff because aiui it's
indefensible.)

> My approach would be to revert bits of it (go back to the xzalloc()
> etc, which is really an attempt to speed up top with less memory churn although
> I should break down and bench what that's spending its time on...)
>
> But if I can't reproduce the failure, I can't bisect it. Hmmm.

yeah, when i get time i'll try the bisection. (unfortunately it's a
multi-hour thing for me. but at that's better than nothing.)

> Rob