[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110713160327.GA24660@openwall.com>
Date: Wed, 13 Jul 2011 20:03:27 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: cluts review
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
