Re: done digging around test-dprintf-posix2

[Bruce Korb]

On 01/10/11 12:44, Bruno Haible wrote:
> The core file is not necessarily an entirely faithful image of
> the address space of the running process.

That is, indeed, the cause of my confusion.

"size core" shows allocated space, but not shared library space
for libraries that weren't really used.  The needed address space
was merely reserved.  Sufficient to cause brk() to fail, but
not important enough to save in the core.  Too clever.  :(

I had previously looked at the maps file, but must have made
a typo in counting up the spaces.  This time, I got the full 10 meg.
10 meg plus, actually.  It would be nice, indeed, if setrlimit
were to return EINVAL when requesting a soft (or hard) limit smaller
than the current in-use size.  The "may" is too weak.

ERRORS
....
       The setrlimit() function may fail if:
       EINVAL The limit specified cannot be lowered because current
              usage is already higher than the limit.

Linux actually allows an rlim_max smaller than the current in-use size,
but setting rlim_cur too small should trigger something, too.  It doesn't.

===================

Back to the patch.  Adding a dprintf/fprintf call to the "is this
working" test should be done.  If triggered, then emit something
to indicate that the test is in need of an increase in the address
space limitation.  The current 10Meg is commented as needing to be
that big to accommodate the program itself, whereas it must be big
enough to have a reserved address space for all the libraries that
may (or may not) get loaded into the address space.  It is not
(sometimes) for libposix.

Maybe it would be easier to capture alloc/free calls that the
rpl_dprintf/rpl_fprintf(?) procedures make?  You are really only
testing the gnulib implementation of these functions, after all.
Not everything else.

Whatever.  For now, the easiest fix is to just double NUM_ROUNDS,
though that does not test out-of-date-ness for the future.