Re: [RFA] Crasher bug in infptrace.c

[Andrew Cagney <ac131313@cygnus.com>]

> 
> 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