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? > 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); 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...?) 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. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
