<div dir="auto">the manual tester of realpath is happy, and i've seen no flake from the bots with tar (but haven't yet heard back from the manual tester of `tar --sort=name`). so far, so good!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 7, 2023, 17:10 enh <<a href="mailto:enh@google.com">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Feb 7, 2023 at 1:34 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank" rel="noreferrer">rob@landley.net</a>> wrote:<br>
><br>
> On 2/7/23 10:42, enh wrote:<br>
> > On Mon, Feb 6, 2023 at 7:35 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank" rel="noreferrer">rob@landley.net</a>> wrote:<br>
> >> On 2/6/23 12:07, enh wrote:<br>
> >> >> > -*-<br>
> >> >> ><br>
> >> >> > as for the new tar, i updated the prebuilts yesterday and we've seen<br>
> >> >> > enough OOM kills since that i've had to revert it.<br>
> >> >><br>
> >> >> Grrr. I've got a couple of suspects for what I screwed up, but... Lemme see if I<br>
> >> >> can work the ASAN leak detector into my workflow at all here. (There's a lot of<br>
> >> >> commands that intentionally leak resources on the way out because the OS will<br>
> >> >> free them, but there's a category of commands that should NOT do that because<br>
> >> >> they process theoretically unbounded input and cannot be allowed to leak-per.)<br>
> >><br>
> >> I haven't wired up the ASAN leak detector yet.<br>
> ><br>
> > i don't think there's a leak.<br>
><br>
> There was on the create side, but it was just metadata not data, and I think I<br>
> fixed it. (I'm still unhappy with glibc's heap behavior, but I think that's just<br>
> glibc being glibc...)<br>
><br>
> >> > read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,<br>
> >> > 512) = 512<br>
> >> > kill(3992265, SIGKILL)                  = 0<br>
> >> > wait4(3992265, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3992265<br>
> >> > exit_group(0)                           = ?<br>
> >> > +++ exited with 0 +++<br>
> >><br>
> >> ... OOM killer maybe?<br>
> ><br>
> > no, sorry --- this was the point i was trying to make. _you're_<br>
> > calling kill(). (if it was the OOM killer, you'd just see the signal<br>
> > appear out of nowhere.)<br>
> ><br>
> > i think this is probably the earlier race workaround coming back to<br>
> > bite us? <a href="https://github.com/landley/toybox/blob/master/toys/posix/tar.c#L1120" rel="noreferrer noreferrer" target="_blank">https://github.com/landley/toybox/blob/master/toys/posix/tar.c#L1120</a><br>
><br>
> *blink* *blink*<br>
><br>
> Oh right, that first patch did two things. Not the dirtree fiddling, the<br>
> wait-for-child logic. Which is gonna report error if we killed the child, and<br>
> now we're listening for that.<br>
><br>
> So instead I need a read-into-toybuf loop to discard trailing input? Hmmm, does<br>
> tar do the same concatenate logic cpio does... no it does not, it just ignores<br>
> the second tarball when you cat two .gz tars together on its input. I can do that.<br>
><br>
> Try now?<br>
<br>
thanks --- that seems to work for me locally.<br>
<br>
i'll start the process, and let you know if the build servers notice<br>
anything... should know by the end of the week!<br>
<br>
> >> Seems to have worked with the test binary I made before that last checkin?<br>
> >> Unless the -C or explicit -j were doing something weird, or I need more to the<br>
> >> reproduction sequence. (Built with NDK or musl...?)<br>
> ><br>
> > it's definitely flaky for me, but i was able to reproduce most of the<br>
> > time. given my suspicion that it's related to your earlier attempt to<br>
> > deal with a race condition, the active ingredient between my 8/10<br>
> > failure rate and your inability to repro might just be "i have a<br>
> > really fast machine"?<br>
><br>
> Yeah, "can it write it all into the pipe buffer" was a race in the first place,<br>
> now you were seeing the other side of that. :P<br>
><br>
> Hopefully fixed now?<br>
><br>
> >> Rob<br>
><br>
> Still Rob<br>
</blockquote></div>