Re: cluts review

[Solar Designer <solar@openwall.com>]

Luka, Rich -

The below is not criticism, but just some feedback on my test run of
cluts earlier today.

So, with the changes that I described before, I built cluts on a glibc
2.3.6'ish linux-threads system (yes, pre-NPTL).

Then I ran it under an account with RLIMIT_AS set to 400 MB:

$ ulimit -v
409600
$ ./cluts
Executing 'alloc' test collection...
<multithreaded>
</multithreaded>
malloc 'allocated' unwritable memory
malloc 'allocated' unwritable memory
malloc 'allocated' unwritable memory

It ran for a while, then went to sleep.

$ ps axu
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
sandbox  21173  0.0  0.2   2400  1504 pts/5    S    14:05   0:00 -bash
sandbox  21480  0.0  0.0   1932   512 pts/5    S+   14:13   0:00 ./cluts
sandbox  21481 29.7 73.9 402768 381328 pts/5   S+   14:13   1:02 ./cluts
sandbox  21484  0.0  0.2   2396  1464 pts/6    S    14:13   0:00 -bash
sandbox  21500  0.0 73.9 402768 381328 pts/5   S+   14:14   0:00 ./cluts
sandbox  21504  0.0 73.9 402768 381328 pts/5   S+   14:14   0:00 ./cluts
sandbox  21522  0.0  0.2   2400  1500 pts/7    S    14:15   0:00 -bash
sandbox  21542  0.0  0.1   1564   548 pts/7    S+   14:16   0:00 cat
sandbox  21545  0.0  0.1   2432   916 pts/6    R+   14:17   0:00 ps axu

top:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21556 sandbox   18   0   956  956  780 R  2.0  0.2   0:00.35 top
21173 sandbox    9   0  1504 1504 1140 S  0.0  0.3   0:00.15 bash
21480 sandbox    9   0   512  512  420 S  0.0  0.1   0:00.00 cluts
21481 sandbox    9   0  372M 372M  464 S  0.0 74.0   1:02.43 alloc
21484 sandbox    9   0  1464 1464 1112 S  0.0  0.3   0:00.05 bash
21500 sandbox    8   0  372M 372M  464 S  0.0 74.0   0:00.09 alloc
21504 sandbox    9   0  372M 372M  464 S  0.0 74.0   0:00.10 alloc
21522 sandbox   10   0  1504 1504 1144 S  0.0  0.3   0:00.06 bash

The "unwritable memory" allocation is probably a glibc issue, albeit a
minor one because malloc() may return such allocations anyway unless
overcommit is fully disabled in the kernel.  The only issue is that for
hitting RLIMIT_AS, it could actually detect the inability to allocate
more address space, so it'd return NULL, which apparently it didn't.

As to cluts going to sleep, this is probably a bug in alloc.c.  If this
file is going to be rewritten, then it might not make sense to chase the
bug down now.  But it is useful to re-test the new version with low
RLIMIT_AS as well.

After a while, I killed the alloc thread that consumed the most CPU time.

(BTW, all of them are just ./cluts in "ps" because cluts.c passes its
own argv[0] to exec.  Perhaps it'd be nicer to fix that.)

The 'alloc' test collection crashed!
Executing 'buf' test collection...
ttyname_r(STDERR_FILENO, s, sizeof(s)-1) failed to set errno=ERANGE (it is E2BIG)
The 'buf' test collection failed 256 test(s).
Executing 'numeric' test collection...
strtoumax("0x", &endptr0) offsets endptr by 1 instead of by 0
strtoumax("0x 1", &endptr0) offsets endptr by 1 instead of by 0
strtoumax("0x+1", &endptr16) offsets endptr by 1 instead of by 0
strtoumax("0x-1", &endptr16) offsets endptr by 1 instead of by 0
strtoumax("0Xx", &endptr16) offsets endptr by 1 instead of by 0
strtoumax("0xX", &endptr16) offsets endptr by 1 instead of by 0
strtof("1e", &endptr, 16) should return 0.000000(0x0p+0), errno=<any>
        instead, it returns 1.000000(0x1p+0), errno=0(Success)

I got lots of errors from "numeric" - I didn't bother recording most.
The above are just a few of them.

The 'numeric' test collection failed 16384 test(s).
Executing 'string' test collection...
The 'string' test collection passed.

Test collections passed: 1/4

This is the known issue with number of failed test collections, right?
Should have been 2, I guess.

Thanks,

Alexander