Stefano Lattarini wrote: ... >> Same with 60MB, but it passes with 70MB. >> So I suggest changing s/50/70/ in both the patch and the log message. >> Maybe even 90 or 100, just to be a little more future/bloat-proof. >> > Since we are being liberal already, let's go for 150 MB then ;-) > > What about the updated, attached patch?
Looks fine, modulo a typo in a new comment. ... >>From 9b06cda000e86888abfc9999b4c66ab8df10873a Mon Sep 17 00:00:00 2001 > Message-Id: > <9b06cda000e86888abfc9999b4c66ab8df10873a.1324983405.git.stefano.lattar...@gmail.com> > From: Stefano Lattarini <stefano.lattar...@gmail.com> > Date: Tue, 27 Dec 2011 10:40:57 +0100 > Subject: [PATCH] tests: fix spurious failure of cond29.test ... > # or cpu time it can found. > +# Limit memory available to spawned processes to ~ 150 MB. This might > +# seem too liberal, but it is needed to account for present and features s/features/future/ I would say that 70MB is enough, but we're allowing for more. The 150MB isn't really needed. # Limit memory available to spawned processes to ~ 150 MB. Considering # that 70 MB is enough for x86_64 Fedora 16, that gives tools and libraries # plenty of room to grow. > +# "bloating" of automake, perl, or even the C library (especially on 64 > +# bit machines). Suggested by Jim Meyering in automake bug#10374. > (ulimit -v 1; sh -c ":") && skip_ "no adequate 'ulimit' builtin found" > -(ulimit -v 20000; sh -c ":") || skip_ "no adequate 'ulimit' builtin found" > -ulimit -v 20000 > - > -for i in 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22; > do > +(ulimit -v 150000; sh -c ":") || skip_ "no adequate 'ulimit' builtin found" > +ulimit -v 150000 > + > +for i in \ > + 01 02 03 04 05 06 07 08 09 10 \ > + 11 12 13 14 15 16 17 18 19 20 \ > + 21 22 23 24 > +do > unindent >>Makefile.am <<EOF > if C$i > bin_PROGRAMS += a$i
