Re: test-fprintf-posix3.c:

[Bruno Haible]

Hi Bruce,

> The test should emit more diagnostics when it fails.
> The amount of trouble one has to go to to show you
> this is extreme.

It is hardly possible to write tests in such a way that
  1) they are silent by default,
  2) when there is a problem at any place, you have all necessary information
     available, without starting a debugger and without adding fprintf
     statements.
If we were to write tests in this way, it would require 3 times more effort
when writing the tests.

Yes, investigating test failures is boring. Recompiling with -g, adding
fprintfs, etc. etc.

> Cool.  I am not a big fan of reverse engineering.
> Explain what is going on with comments or something, please.

That test has comments every 11 lines of code on average. This should be
enough.

> Creating a debuggable binary is quite a nuisance, what with
> all the libtool convolutions.

Maybe it is these "convolutions" that cause the problem for you and Gary,
- while I don't observe it in a testdir that does not use libtool ? What
are the sizes of the executable, shared library, etc. for you?

> Breakpoint 2, main (argc=2, argv=0x7fffffffdd38)
>     at ../../tests/test-fprintf-posix3.c:97
> 97              return 1;
> (gdb) p repeat
> $1 = 0
> (gdb) p errno
> $2 = 12
> $ egrep ENOMEM $(find /usr/include -type f -name 'err*.h')
> /usr/include/asm-generic/errno-base.h:#define ENOMEM 12
> 
> It returned ENOMEM on the first try.

So, my guess would be that the 10 MB address space were not sufficient.
What if you bump it to 20 MB (i.e. increase NUM_ROUNDS from 1000 to 2000)?

Bruno