Re: [RFA] Crasher bug in infptrace.c

[Michael Snyder <msnyder@redhat.com>]

Andrew Cagney wrote:
> 
> >
> > 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.

I spent an hour thinking about how to do that (without significantly
uglifying the code), and decided it was more trouble than I wanted to
go to.  I agree with you -- the function doesn't require a buffer 
at all.  Anyone who wants to rewrite the function to that extent
is more than welcome to by me.  ;-)