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
>>
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 $(f
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 $(f
s.
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=0x7fffdd38)
> at
in a permanent memory allocation. */
95if (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.
(
st is expected
to fail with status 1 or to crash inside the memset invocation.
> Breakpoint 1, main (argc=2, argv=0x7fffdd38)
> at ../../tests/test-fprintf-posix3.c:57
> 57if (getrlimit (RLIMIT_DATA, &limit) < 0)
> (gdb)
> 59if (limit.rlim_max == RLIM_INF
ils on
an allocation, perhaps you want to allocate a large chunk and
then allocate little nibbles until you fail, *THEN* try the
printf call, yes?
Breakpoint 1, main (argc=2, argv=0x7fffdd38)
at ../../tests/test-fprintf-posix3.c:57
57if (getrlimit (RLIMIT_DATA, &limit) < 0)
(gdb)
5
