[RFA] Crasher bug in infptrace.c
Andrew Cagney
ac131313@cygnus.com
Thu Jan 3 11:58:00 GMT 2002
>
> Will do.
>
>
>
>> > + int alloc = count * sizeof (PTRACE_XFER_TYPE);
>> > + PTRACE_XFER_TYPE *buffer;
>> > +
>> > /* Allocate buffer of that many longwords. */
>> > ! if (len < GDB_MAX_ALLOCA)
>> > ! {
>> > ! buffer = (PTRACE_XFER_TYPE *) alloca (alloc);
>> > ! }
>> > ! else
>> > ! {
>> > ! buffer = (PTRACE_XFER_TYPE *) xmalloc (alloc);
>> > ! make_cleanup (xfree, buffer);
>> > ! }
>
>>
>> I think it would be better to just abandon the alloca() case and just
>> use xmalloc(). That way the same code path (xmalloc()) is always used
>> and mysterious / obscure bugs that end up being attributed to
>> len?=GDB_MAX_ALLOCA can be avoided.
>
>
> I don't think so -- this function gets called a lot. Heavy use of
> xmalloc on small buffers might lead to fragmentation. Let's try the
> idea of using alloca for small buffers and xmalloc for big ones.
I think trying to tune an alloca() buffer size is really dangerous.
GDB's crashability starts to depend on how many alloca's have gone
before / after the above call. Regarding fragmentation, wouldn't it be
better to get the code working correctly and only when fragmentation is
demonstrated to be a problem, modify the algorithm.
Anyway, looking at the code, I'm wondering if it would actually be
better to just eliminate that bounce buffer and, instead just transfer
the data directly. This might leave the buffer in an undefined state, I
think, however, that is ok.
Andrew
More information about the Gdb-patches
mailing list