Re: test-fprintf-posix3.c:

[Bruno Haible]

Bruce Korb wrote:
> I finally ... used GDB.

Good.

> RLIMIT_DATA and RLIMIT_AS appear to be set to 10,000,000.
> An attempt to malloc 10 million (MAX_ALLOC_TOTAL) fails
> and the two failing tests exit with status "1".

When you look at test-fprintf-posix3.sh: The first test is expected
to fail with status 1 or to crash inside the memset invocation.

> Breakpoint 1, main (argc=2, argv=0x7fffffffdd38)
>     at ../../tests/test-fprintf-posix3.c:57
> 57        if (getrlimit (RLIMIT_DATA, &limit) < 0)
> (gdb)
> 59        if (limit.rlim_max == RLIM_INFINITY || limit.rlim_max > 
> MAX_ALLOC_TOTAL)
> (gdb)
> 60          limit.rlim_max = MAX_ALLOC_TOTAL;
> (gdb)
> 61        limit.rlim_cur = limit.rlim_max;
> (gdb)
> 62        if (setrlimit (RLIMIT_DATA, &limit) < 0)
> (gdb) p limit
> $1 = {rlim_cur = 10000000, rlim_max = 10000000}
> (gdb) n
> 67        if (getrlimit (RLIMIT_AS, &limit) < 0)
> (gdb)
> 69        if (limit.rlim_max == RLIM_INFINITY || limit.rlim_max > 
> MAX_ALLOC_TOTAL)
> (gdb)
> 70          limit.rlim_max = MAX_ALLOC_TOTAL;
> (gdb)
> 71        limit.rlim_cur = limit.rlim_max;
> (gdb)
> 72        if (setrlimit (RLIMIT_AS, &limit) < 0)
> (gdb) p limit
> $2 = {rlim_cur = 10000000, rlim_max = 10000000}
> (gdb) n
> 76        arg = atoi (argv[1]);
> (gdb)
> 77        if (arg == 0)
> (gdb) p arg
> $3 = 0
> (gdb) n
> 79            void *memory = malloc (MAX_ALLOC_TOTAL);
> (gdb)
> 80            if (memory == NULL)
> (gdb) p memory
> $4 = (void *) 0x0

That is all normal.

The question then is, why does the second run ("run 1" or
"run 1 > /dev/null" in gdb) fail with exit code 1?

The code repeats 1000 times a loop with an fprintf call that
is expected to use up to 11000 bytes of temporary memory. If that
temporary memory is freed after use, or reused in the subsequent
calls, everything is fine. If, however, there is a memory leak,
then at most 909 loop rounds will succeed, and after that one
loop round will exhibit the ENOMEM error.

> If your intent is to squeeze the heap so that printf fails on
> an allocation, perhaps you want to allocate a large chunk and
> then allocate little nibbles until you fail, *THEN* try the
> printf call, yes?

Not exactly. The test wants to see if the mere use of fprintf squeezes
the heap or not.

Maybe the first information you can provide after "run 1" is the value
of the variable 'repeat' when it exits. I expect something around 800..909.
Then look at the state of the malloc whether really nearly 10 MB have been
eaten up. Or look at the source code that implements fprintf, to see where
the buffer is allocated but never freed.

Bruno