Re: patch for printf memory use tests

[Bruce Korb]

On 01/14/11 16:10, Bruno Haible wrote:
> Hi Bruce,
> 
>> This patch does a few things:
>>
>> 1. It increases the number of iterations of the test-fprintf-posix3
>>    and test-dprintf-posix2 to 1,500 so that 15MB of address space
>>    is allowed.
> 
> This may be the right thing to do. Or maybe the right thing to do
> is to getrlimit (RLIMIT_AS,) with a value that is computed as
> (size of address space of current process before any malloc) + 10 MB.

Hi Bruno,

I think these _are_ the right things to do.  Both bump the size and
also test for bumping against it again in the future in a way that
lets the next hapless coder know what the issue is without having
to go through a bunch of somersaults to figure it out.

Also, I did look at the convolutions required to determine the
current address space size (Viz., opening /proc/self/maps and
parsing the text).  My conclusions:

1. It is Linux specific
2. It is a nuisance
3. The test is designed to catch a mis-implementation of the printf
   functionality.  Once upon a time, someone likely forgot to free
   the temporary buffer.  The test really belongs in a "stability
   regression test" suite, rather than where it is.  Therefore,
   it doesn't really seem like it is worth jumping through a lot
   of hoops.
4. Despite not using libpthread, libm or librt, the address space required
   to page these in is pre-allocated.  However, because the libraries
   are not actually paged in, the "size" program doesn't report the
   address space consumption.

Also, I think I mentioned here somewhere that doing a setrlimit of
the current size to less than what is currently in use "may" cause
setrlimit to return EINVAL, if the implementers choose to do so.
They did not so choose for Linux.  It'd have made this much easier.

> Could you please show us the contents of the /proc/$pid/maps file, at
> a time point before the dprintf() or malloc() calls?

I only posted it to the bug report.  Sorry.  The before and after
results are identical, by the way.  malloc() failed.

Anyway, there's more than 10 meg, it is just horribly ugly reading.
(I wrote an ad-hoc shell script to read, parse and sum the spaces.
Trust Me.)

Oh, wait, using "readelf" on the core image I posted here:
> http://autogen.sourceforge.net/data/dprintf-posix2.core
yields this:

$ readelf --segments *core*|fgrep -v LOAD|(
> sum=0;while read line
> do set -- $line;case "$2" in (0x*) (( sum += $2 )) ;; esac
> done ; printf "0x%08X == %12d\n" $sum $sum)
0x00A2E708 ==     10675976

$ cat /proc/8496/maps
00400000-00404000 r-xp 00000000 09:00 4228629               
.../tests/test-fprintf-posix3
00604000-00605000 r--p 00004000 09:00 4228629               
.../tests/test-fprintf-posix3
00605000-00606000 rw-p 00005000 09:00 4228629               
.../tests/test-fprintf-posix3
7ffff7401000-7ffff7418000 r-xp 00000000 08:06 9043976       
/lib64/libpthread-2.11.2.so
7ffff7418000-7ffff7618000 ---p 00017000 08:06 9043976       
/lib64/libpthread-2.11.2.so
7ffff7618000-7ffff7619000 r--p 00017000 08:06 9043976       
/lib64/libpthread-2.11.2.so
7ffff7619000-7ffff761a000 rw-p 00018000 08:06 9043976       
/lib64/libpthread-2.11.2.so
7ffff761a000-7ffff761e000 rw-p 00000000 00:00 0
7ffff761e000-7ffff7774000 r-xp 00000000 08:06 9044083       
/lib64/libc-2.11.2.so
7ffff7774000-7ffff7974000 ---p 00156000 08:06 9044083       
/lib64/libc-2.11.2.so
7ffff7974000-7ffff7978000 r--p 00156000 08:06 9044083       
/lib64/libc-2.11.2.so
7ffff7978000-7ffff7979000 rw-p 0015a000 08:06 9044083       
/lib64/libc-2.11.2.so
7ffff7979000-7ffff797e000 rw-p 00000000 00:00 0
7ffff797e000-7ffff79d4000 r-xp 00000000 08:06 9044230       
/lib64/libm-2.11.2.so
7ffff79d4000-7ffff7bd3000 ---p 00056000 08:06 9044230       
/lib64/libm-2.11.2.so
7ffff7bd3000-7ffff7bd4000 r--p 00055000 08:06 9044230       
/lib64/libm-2.11.2.so
7ffff7bd4000-7ffff7bd5000 rw-p 00056000 08:06 9044230       
/lib64/libm-2.11.2.so
7ffff7bd5000-7ffff7bdd000 r-xp 00000000 08:06 9044289       
/lib64/librt-2.11.2.so
7ffff7bdd000-7ffff7ddc000 ---p 00008000 08:06 9044289       
/lib64/librt-2.11.2.so
7ffff7ddc000-7ffff7ddd000 r--p 00007000 08:06 9044289       
/lib64/librt-2.11.2.so
7ffff7ddd000-7ffff7dde000 rw-p 00008000 08:06 9044289       
/lib64/librt-2.11.2.so
7ffff7dde000-7ffff7dfd000 r-xp 00000000 08:06 9044076       /lib64/ld-2.11.2.so
7ffff7fc8000-7ffff7fcc000 rw-p 00000000 00:00 0
7ffff7ffa000-7ffff7ffb000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0             [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 0001e000 08:06 9044076       /lib64/ld-2.11.2.so
7ffff7ffd000-7ffff7ffe000 rw-p 0001f000 08:06 9044076       /lib64/ld-2.11.2.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0             [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0     [vsyscall]