------- Original Message ------- On Monday, October 9th, 2023 at 17:29, Rob Landley <r...@landley.net> wrote:
> 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.) Yeah, I tried making those warnings go away too, I couldn't get anything that looked clean to work > > > > # 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 Test suite now passes on tar, thanks > > > > > 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 Test suite passes on truncate, thanks > > > > 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. Huh, now sed passes it's tests by being faster. And _also_ mkpasswd passes it's tests too. You'd think having a program counter of 0 would cause a segfault, or at least the program wouldn't pass it's tests. But apparently not > 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, Huh, pulling the latest commit and running "VERBOSE=allnopass make tests" doesn't give the ASAN dumps anymore for me. Thanks for fixing the errors > 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 The only command that fails for me now is du, The 3 tests that fail are "du counts symlinks without following", "du -LH does not follow unspecified symlinks", and "du -H does not follow unspecified symlinks" All 3 give the same diff: @@ -1 +1 @@ -8 du_test +12 du_test > _______________________________________________ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net - Oliver Webb <aquahobby...@proton.me> _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net