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

[Oliver Webb]

------- Original Message -------
On Friday, October 6th, 2023 at 00:33, Rob Landley <rob at landley.net> wrote:


> On 10/5/23 22:50, Oliver Webb via Toybox wrote:> I ran "VERBOSE=allnopass make
>
> tests" to see exactly what was still broken.
>
> Note that all of them pass for me.

I was not aware of this, I would have given more explanation to the other errors if I thought
they were not already known

> > (du has some symlink issues,
>
>
> On what filesystem?
>
> > tar has a long filename issue,
>
>
> Hadn't seen that one, I'm aware of a sparse file issue on some filesystems.
> (That hit on microsoft github.)

My home directory is ecryptfs, Testing on my /tmp directory (etx4) makes the errors
go away for both du and tar. The specific test that fails with tar is "tar create long->long".
Oh, another one I forgot to mention is "truncate sparse" fails on ecryptfs as well, but works on ext4

> > sed fails the performance test even though it can process a megabyte of data in less then 20s,
>
>
> On what hardware?

A laptop with 4GB of RAM and about 2.5 Gigahertz of processing power with 2 cores (Intel Celeron).
This doesn't seem like a hardware speed issue

(seq 160000 generates about a MB of data so I used that in this test instead of the 20 doublings sed.test does)
$ time ( seq 160000 | toybox sed "s/./y/g" > /dev/null )

real    0m0.282s
user    0m0.235s
sys     0m0.049s


> > and the test passes on "make test_sed",
>
>
> Does it still happen with the most recent commit to timeout? 

I tested on the most recent commit to toybox

> (Did it just
> start happening with the most recent commit to timeout?)

When I first started looking at toybox (0.8.9 I think?) the du and tar bugs were there.
But I don't remember sed having any issues like this back then. make test_timeout shows no errors

> Because the big
> difference between the two is using your host $PATH for the commands other than
> sed. The "make tests" setup puts all the toybox commands at the start of the
> $PATH and uses them to test each other.
>
> Again, it passed for me.
>
> > mkpasswd segfaults due to a null pointer sometimes, etc)
>
>
> I haven't seen this (what distro/compiler/libc/filesystem are you testing on),

Linux Mint 21.1 (Which is essentially Ubuntu 22.04 with some irrelevant changes)/GCC 11.4.0
/glibc 2.35/ecryptfs and etx4 (Both experience the same mkpasswd errors)

Huh, I just tested with make test_mkpasswd and it worked, Another one like tsort where it triggers
ASAN _only_ when in a multicall binary.

> but I mentioned I just redid the lib/password.c plumbing and need to re-audit
> that list of commands before next release.

Here's the error message ASAN sends:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==15453==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7ffd90ffb280 sp 0x7ffd90ffb1a8 T0)
==15453==Hint: pc points to the zero page.
==15453==The signal is caused by a READ memory access.
==15453==Hint: address points to the zero page.
    #0 0x0  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
==15453==ABORTING

(ASAN catching reading from a null pointer and "SEGV"-ing is different from the kernel catching one
and sending a SIGSEGV for a reason I don't know)


> > To my surprise, Every test from tsort failed, along with some messages from
> > a "AddressSanitizer".
>
>
> Sigh, I moved the initializations between the two nested loops and the local
> variable declarations enough times I apparently dropped the plen initialization.
>
> Try commit 47946f241a4e.

Works perfectly, thanks

> > Compiling a multicall binary and running tsort (sometimes)
> > shows this message on boot:
>
>
> Yeah, uninitialized variable it doesn't warn about. My bad. (And ASAN doesn't
> catch the ones where it is initialized to zero because this is the first call
> on clean stack. Presumably there's some stack poisoning option somewhere...)
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net

- Oliver Webb <aquahobbyist at proton.me>