This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Crasher bug in infptrace.c
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. ;-)