[Toybox] [PATCH] Fix hang in losetup test.

[Rob Landley]

On 01/22/2018 04:08 PM, enh wrote:
> Switch the printf over to %s because the input is actually hex (so %d
> is wrong), but without the leading "0x" that %x would require.
> 
> For some reason the NODE assignment wasn't providing any input to awk
> (hence the hang),

Because I was going to save the stat output in an environment variable
and then parse the two fields out of that rather than calling stat twice
(more or less out of habit from "fetching data fro the same file twice?
Race condition, it could change between!")...

> and awk wasn't looking for the correct field anyway.
> 
> The tests still fail for me:
> 
>   losetup: /dev/block/loop0: No such device or address
>   losetup: /dev/block/loop0: No such device or address
>   losetup: file: No such file or directory
>   losetup: needs 1 arg (see "losetup --help")
> 
> But at least now they allow the other tests to continue!

I really, really, really need tests/pending. I have no idea why that
file is checked in. (Probably I was thinking of some other command's
tests.) It's basically a couple notes to self for when I actually
implement these tests.

I need to do losetup tests but it's in the "needs root" bucket which
means "needs qemu" which means "needs mkroot"...

This isn't even a hard one (ala bind mounting stuff over /proc to get
reproducible ps tests, or the "ptywrap" thing I need to write to test
the screen width queries in ls and ps and such). It just needs the basic
"run this test as root with known kernel config in a freshly rebooted
system (so nobody's already _using_ any of the loop devices and we get
consistent numbers) which we can shut down afterwards so tests that fail
in a way that prevents us from cleaning up after them doesn't make me
reboot my netbook to get back to a known state..." (Ok, yeah, thats a
long stretch of quote marks.)

Lemme see if I can find some time to shovel this out too...

Rob

P.S. All root tests are a _bit_ funky because I also wanna make
TEST_HOST pass for them, and getting non-toybox implementations
similarly wrappered? Probably debootstrap and package it into an ext3
root filesystem I can plug into the same kernel under qemu. It's on the
todo list. No a container isn't quite good enough if for example the
tests needs to ensure the equivalent of "insmod dummy" is available. Not
unless I tailor the tests to expect a specific version of a specific
distro, which is bit-rot waiting to happen...

P.P.S. what I REALLY need it some way to force ps or top to deal with
processes exiting while it's examining them. But even if I did something
truly horrible with ptrace or perhaps a fuse filesystem providing a fake
ps, it would only test certain specific "file goes away between this
operation and that operation", which are the kind of specific things I'd
already have fixed if I noticed them and knew to test for them. Alas,
fuzzing seems the only way to really get good coverage there, and this
is really a regression test suite built around deterministic behavior.