[Toybox] grep getdelim() and errno

[enh]

On Fri, Mar 12, 2021 at 12:43 AM Rob Landley <rob at landley.net> wrote:

> On 3/11/21 6:16 PM, enh via Toybox wrote:
> > attached is the patch that's the reason why this morning i went through
> the
> > other places where toybox looks at errno without first checking that the
> > function call failed...
> >
> > i think we should take this fix since POSIX allows errno to be clobbered
> by a
> > successful call to most functions ["The setting of errno after a
> successful call
> > to a function is unspecified unless the description of that function
> specifies
> > that errno shall not be modified"], and that certainly happens in
> practice.
> >
> > there's definitely something odd going on here though. the reason i've
> not added
> > a test case is that i can't reproduce this at all on glibc/x86-64, nor on
> > bionic/x86-64. i can reproduce it on bionic/arm64, but not quite as
> reliably as
> > the person who hit this in practice while doing real work (and they only
> see it
> > 1/100 runs). but what we do have in common is that we're seeing errno
> set to
> > ENOENT (!), and i have no explanation for how getdelim() is clobbering
> errno
> > with that specific value. so i think we have more than one bug, but this
> is a
> > bug regardless, so... patch attached.
>
> Sigh. I'm not gonna argue with reality occurring in the field, but
> EEEEWWWWW.
>
> Applied.
>
> Rob
>
> P.S. It's because the function is calling other functions internally which
> can
> fail and be fixed up or retried. My first guess would be down under the
> reallocarray call on line 106 of getdelim.c,


yeah, the person who first hit this claims it's happening from the calloc()
in recallocarray(), but statically at least, there's no way our allocator
can return ENOENT. (and i do have an strace that shows the ENOENT isn't
from any system call.)

sadly i'm out of devices and disk space right now so i can't go printf()
debugging, but there's definitely something very odd going on here.


> and does it happen under arm64 kvm
> because that returns buckets of ENOENT every time you look at it funny.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210312/439e5d4a/attachment-0001.htm>