Re: done digging around test-dprintf-posix2

[Bruno Haible]

Hi Bruce,

> I now believe it completely correct to add this:  free(malloc(0x88))
> to the program and put it into the main line until the real cause
> (glibc or kernel) is determined and fixed.

What is your explanation of why that free(malloc(0x88)) has the effect
of avoiding the crash?

If I understood things correctly from your Jakub Jelinek's reply to your
report <http://sourceware.org/bugzilla/show_bug.cgi?id=12232>, then the
effect of free(malloc(0x88)) is that is pre-allocates some memory pages,
to such an extent that the mallocs inside rpl_fprintf or rpl_dprintf
succeed. We don't want this, as it only masks a problem that is still
present inside rpl_fprintf or rpl_dprintf.

Ulrich and Jakub pointed you to the fact that it's the kernel who decides.
Have you tracked down in the kernel the source code that refuses memory
allocations, depending on the RLIMIT_AS value? At that moment when malloc
fails, what are the memory maps (/proc/<pid>/maps) and what was the system
call (strace!) that the malloc() call translated into?

And what is the size of the 'test-dprintf-posix2' program with all its
dependencies (as shown by 'ldd')? Does it sum up to more than 10 MB?

> Clear to send?

Not without a convincing explanation, and not without comments in the code
that explain what is going on.

If you cannot produce a small test program that proves a bug in glibc,
then it is better to leave the test as is, and wait for someone else to
investigate further.

Bruno