On 11/11/10 01:20, Bruno Haible wrote:
> Bruce Korb wrote:
>> I finally ... used GDB.
>
> Good.
The test should emit more diagnostics when it fails.
The amount of trouble one has to go to to show you
this is extreme.
>> 79 void *memory = malloc (MAX_ALLOC_TOTAL);
>> (gdb)
>> 80 if (memory == NULL)
>> (gdb) p memory
>> $4 = (void *) 0x0
>
> That is all normal.
Cool. I am not a big fan of reverse engineering.
Explain what is going on with comments or something, please.
Creating a debuggable binary is quite a nuisance, what with
all the libtool convolutions.
> Not exactly. The test wants to see if the mere use of fprintf squeezes
> the heap or not.
I don't particularly like reverse engineering.
Comments in both the script and the code would be helpful.
Also, saving error out on failure would be nice. Thanks.
> Maybe the first information you can provide after "run 1" is the value
> of the variable 'repeat' when it exits. I expect something around 800..909.
> Then look at the state of the malloc whether really nearly 10 MB have been
> eaten up. Or look at the source code that implements fprintf, to see where
> the buffer is allocated but never freed.
(gdb)
91 for (repeat = 0; repeat < NUM_ROUNDS; repeat++)
92 {
93 /* This may produce a temporary memory allocation of 11000 bytes.
94 but should not result in a permanent memory allocation. */
95 if (fprintf (stdout, "%011000d\n", 17) == -1
96 && errno == ENOMEM)
97 return 1;
98 }
99
100 return 0;
(gdb) b 97
Breakpoint 2 at 0x400a86: file ../../tests/test-fprintf-posix3.c, line 97.
(gdb) b 100
Breakpoint 3 at 0x400a9a: file ../../tests/test-fprintf-posix3.c, line 100.
(gdb) c
Continuing.
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.
