Re: test-dprintf-posix2 failure (was: How about this patch)

[Bruno Haible]

Hi Bruce,

Please choose a meaningful subject to your mail. How could someone keep
track of the 4000 mails that come in through bug-gnulib if many subjects
were "How about this patch", "Second attempt", "Help", and "I've got it"?

> +      /* This "dprintf" can draw in a number of libraries triggering many
> +         changes in the address space.

Is this so? Have you retrieved the contents of /proc/$PID/maps before and
after the dprintf call? Can you show these two, please?

>           There is no trivial way to fiddle 
> +         with getrlimit/setrlimit or even to examine /proc/$PID/maps and
> +         figure out how much of the RLIMIT_AS space we are using

Oh really? libsigsegv has code for reading and parsing /proc/$PID/maps:
  
<http://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=src/stackvma-linux.c>
I'm not saying that this should be included in the test, just that you
should consider looking at /proc/$PID/maps during your analysis.

>      if (dprintf (STDOUT_FILENO, "%011000d\n", 17) == -1
>          && errno == ENOMEM)
>        return 78;
>
>      memory = malloc (MAX_ALLOC_TOTAL);

This code would be a reasonable workaround if all other attempts to nail down
the cause of the problem failed. But I gave you 3 other clues in the other
mail: look at /proc/$PID/maps, produce a test case for the glibc people, and
produce a test case for the kernel people.

Bruno