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
