Re: one last snapshot before test release

[Matthew Woehlke]

Jim Meyering wrote:
> Matthew Woehlke <address@hidden> wrote:
> > Paul Eggert wrote:
> > > Matthew Woehlke <address@hidden> writes:
> > > > Hooboy. sort-compress failed spectacularly on OSF. From the errors
> > > > (lots of "task_create() failed for pid 12044: maxuprc (=64) exceeded
> > > > for uid <uid>"), it looks like it is blowing some process limit (looks
> > > > like the limit is 64?).
> > > Does the test actually fail, or does it succeed while something is
> > > spewing out those messages?
> > It does actually fail. In fact, from the mountains of diff output it
> > looks like 'sort' *may* be completely failing to output anything, or at
> > least failing to output large chunks of what it is supposed to. I can
> > re-run with VERBOSE, but it's going to be a *big* log, should I bz2 it
> > and post that?
>
> Yes, please.

Attached. It turns out the failure is actually sporadic; it passed 
several times before failing again. This looks suspicious:
[...]
./dzip[2]: cannot fork: too many processes
./dzip[2]: cannot fork: too many processes
task_create() failed for pid 15540: maxuprc (=64) exceeded for uid 306.
task_create() failed for pid 10431: maxuprc (=64) exceeded for uid 306.
[...much of the same...]
./dzip[2]: cannot fork: too many processes
task_create() failed for pid 8367: maxuprc (=64) exceeded for uid 306.
./dzip[2]: cannot fork: too many processes
sort: ./dzip [-d] terminated abnormally
cmp: EOF on out
0a1,2000
> 0001
> 0002
> 0003
> 0004
> 0005
[...]

Unfortunately I cannot include the 'task_create() failed ...' stuff in 
the output, it seems this is being dumped by the OS do the controlling 
TTY, and therefore bypasses attempts to redirect it to a file.

> Also, what version of OSF?

4.0f (what is 4.0 1229? Oh, ok, mine is 4.0 1530 but I've always seen it 
referred to by 4.0<letter> before.)

> I see failures on OSF V4.0 1229, but none involving sort.
> These are the ones that fail for me:
>
>   chown/preserve-root
>   readlink/can-e
>   readlink/can-f
>   readlink/can-m
>
> Failures like these (only on such an old OS) aren't worth
> holding up a test release.

Well... here's the thing. It also fails (or rather, can fail; it seems 
the failure is more *likely* on OSF, but...) on x86_64 Linux 2.6.9 if I 
do 'ulimit -u 64'. So the problem isn't OSF, the problem is a low 
process limit (which I guessed, correctly, from the errors I saw on 
OSF). It just so happens that my OSF box has had the default process 
limit capped to 64, which causes the test to run out of processes, and 
*also* that I got "lucky" and the first time I ran the test failed.

One Linux run choked in "dzip" (what is dzip, anyway?) like OSF, but two 
others died in gzip. The second attached log was made on the first try 
with 'ulimit -c 32'.

--
Matthew
<insert bad pun... on second thought, better not>

sort-compress.out.bz2
Description: BZip2 compressed data

sort-compress_linux.out.bz2
Description: BZip2 compressed data