I've gone as far as I am going with this.
The allocation failure happens in _int_malloc,
but that is a 530 line abomination. Stepping
through that with "stepi" is ridiculous.
MALLOC_CHECK_ did not add any info.
valgrind merely reported that there were no allocations.
$ /lib64/libc.so.6
GNU C Libra
On 11/12/10 07:57, Bruce Korb wrote:
> On 11/11/10 18:51, Bruno Haible wrote:
>>> Breakpoint 2, main (argc=2, argv=0x7fffdd38)
>>> at ../../tests/test-fprintf-posix3.c:97
>>> 97 return 1;
>>> (gdb) p repeat
>>> $1 = 0
>>> (gdb) p errno
>>> $2 = 12
>>> $ egrep ENOMEM $(find /usr
On 11/11/10 18:51, Bruno Haible wrote:
>> Breakpoint 2, main (argc=2, argv=0x7fffdd38)
>> 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/includ
On 11/11/10 18:51, Bruno Haible wrote:
>> Breakpoint 2, main (argc=2, argv=0x7fffdd38)
>> 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/includ
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 infor
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.
>> 79void *memory = malloc (MAX_ALLOC_TOTAL);
>> (gdb)
>> 80
Bruce Korb wrote:
> I finally ... used GDB.
Good.
> RLIMIT_DATA and RLIMIT_AS appear to be set to 10,000,000.
> An attempt to malloc 10 million (MAX_ALLOC_TOTAL) fails
> and the two failing tests exit with status "1".
When you look at test-fprintf-posix3.sh: The first test is expected
to fail wi
