[Toybox] ASan freaks out when using tsort in multicall binaries

[Rob Landley]

I installed a mint vm (xfce flavor) and reproduced your issues. Sent in fixes
for some of them, although your gcc still produces warnings about "unused return
result" even when I typecast the return to (void). (Still, the commit comment
says _why_ each of those return results are not useful to try to do anything
with, and LLVM isn't broken that way. If this regression recurs every few
upgrades, "does not produce spurious warnings on gcc" may not be a defensible
target, especially with all the "is not actually used uninitialized" warnings
still cropping up in 2023.)

>> # 255 bytes, longest VFS name
>> LONG=0123456789abcdef0123456789abcdef
>> LONG=$LONG$LONG$LONG$LONG$LONG$LONG$LONG$LONG
>> LONG=${LONG:1:255}
>>
>> # 4+96=100 (biggest short name), 4+97=101 (shortest long name)
>> touch dir/${LONG:1:96} dir/${LONG:1:97}
>> testing "create long fname" "$TAR dir/${LONG:1:97} dir/${LONG:1:96} | SUM 3" \
>> "d70018505fa5df19ae73498cfc74d0281601e42e\n" "" ""
>>
>> And what I was trying to test was the border condition of the tar internals
>> where it switches over to an adjunct record to record an overlength field that
>> won't fit in the structure, and it sounds like what's failing is the
>> filesystem's ability to have two adjacent directories of length 96 and 97 that
>> differ only by that final character. Except I didn't add a check for failure to
>> the "touch" because it wasn't supposed to be part of the test, I just naively
>> assumed that would portably work...

Commit 71197a67521d

>> > Oh, another one I forgot to mention is "truncate sparse" fails on ecryptfs as well, but works on ext4
>>
>>
>> Do you mean the tests/truncate.test entry:
>>
>> testing "is sparse" "truncate -s 1g freep && [ $(stat -c %b freep) -le 8 ] &&
>> echo okay" "okay\n" "" ""
>>
>> Which is doing a "truncate -s 1g file" and then asking state if the file with
>> literally no contents used less than 8 512-byte blocks of storage?
> 
> That's the one

Commit 19a1a11f305c

>> It's not generating a megabyte of random data, it's generating a megabyte of the
>> same character, and then asking sed search-and-replace replace one byte at a
>> time in that string a million times. The search-and-replace is s/x/y/ meaning
>> each x gets replaced with y. The output of "seq" does not contain any "x"
>> characters, so the search and replace will trigger zero times instead of
>> triggering a million times.

I tested this. If I build toybox sed without ASAN the 1 megabyte search and
replace completes in 0.15 seconds. If I build it with ASAN, it takes 29.35
seconds. The gcc address sanitizer is slowing sed down 200 times.

Elliott and I went over this a year or so back when LLVM introduced (then fixed)
the same regression.

>> Is it triggering ASAN in mkpasswd or in a different toybox command out of the
>> $PATH? (Yay reproduction sequence, but WHAT did it reproduce?)
> 
> Putting toybox commands into my PATH runs test_mkpasswd fine, So I don't think it's some other toybox command.
> And since the lib/password.c plumbing got rewritten and needs to be audited that naturally seemed
> like the issue.

I'm seeing the ASAN dumps, haven't dug into them yet. I chmod -x the mkpasswd
test ("make tests" runs all the tests with the executable bit, because there's
no tests/pending directory) until I've circled back around to this.

Rob