<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 12, 2021 at 12:43 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/11/21 6:16 PM, enh via Toybox wrote:<br>
> attached is the patch that's the reason why this morning i went through the<br>
> other places where toybox looks at errno without first checking that the<br>
> function call failed...<br>
> <br>
> i think we should take this fix since POSIX allows errno to be clobbered by a<br>
> successful call to most functions ["The setting of errno after a successful call<br>
> to a function is unspecified unless the description of that function specifies<br>
> that errno shall not be modified"], and that certainly happens in practice.<br>
> <br>
> there's definitely something odd going on here though. the reason i've not added<br>
> a test case is that i can't reproduce this at all on glibc/x86-64, nor on<br>
> bionic/x86-64. i can reproduce it on bionic/arm64, but not quite as reliably as<br>
> the person who hit this in practice while doing real work (and they only see it<br>
> 1/100 runs). but what we do have in common is that we're seeing errno set to<br>
> ENOENT (!), and i have no explanation for how getdelim() is clobbering errno<br>
> with that specific value. so i think we have more than one bug, but this is a<br>
> bug regardless, so... patch attached.<br>
<br>
Sigh. I'm not gonna argue with reality occurring in the field, but EEEEWWWWW.<br>
<br>
Applied.<br>
<br>
Rob<br>
<br>
P.S. It's because the function is calling other functions internally which can<br>
fail and be fixed up or retried. My first guess would be down under the<br>
reallocarray call on line 106 of getdelim.c, </blockquote><div><br></div><div>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.)</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and does it happen under arm64 kvm<br>
because that returns buckets of ENOENT every time you look at it funny.<br>
</blockquote></div></div>