From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/143 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: cluts review Date: Wed, 13 Jul 2011 20:03:27 +0400 Message-ID: <20110713160327.GA24660@openwall.com> References: <20110713110723.GA22153@openwall.com> <4E1D8964.3020502@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1310573019 22716 80.91.229.12 (13 Jul 2011 16:03:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 16:03:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-227-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 13 18:03:36 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Qh1uO-00051b-H0 for gllmg-musl@lo.gmane.org; Wed, 13 Jul 2011 18:03:32 +0200 Original-Received: (qmail 23686 invoked by uid 550); 13 Jul 2011 16:03:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23678 invoked from network); 13 Jul 2011 16:03:31 -0000 Content-Disposition: inline In-Reply-To: <4E1D8964.3020502@gmail.com> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:143 Archived-At: 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... 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= 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