This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Evaluating arrays in Fortran
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Thu, 9 Oct 2003 11:36:03 -0400
- Subject: Re: [PATCH] Evaluating arrays in Fortran
- References: <20031008230346.GA586@streamline-computing.com>
On Thu, Oct 09, 2003 at 12:03:46AM +0100, David Lecomber wrote:
> This is a patch that makes the evaluation of arrays cause fewer
> segmentation faults in Fortran subroutines where the parameter array
> has a (*) as the bound. The existing implementation allocates the
> entire array and then finds the right element. Unfortunately the (*)
> is recorded as -1 in the symtab, which makes a very nasty malloc..
> This new method is the same as how C arrays are handled.
>
> Note there are still a few other Fortran array problems for
> subroutines - incorrect indexing and other ways to cause seg faults,
> this won't fix them, but it's a start..
>
> Attached is a test program. Put a break in subs, and print out
> (*x)(10,3) -- without the patch, gdb seg faults soon after. With the
> patch it doesn't.
>
>
> 2003-10-08 David Lecomber <dsl@sources.redhat.com>
>
> * eval.c (evaluate_subexp_standard): Don't allocate entire array
> locally to read array values in Fortran; allocate required element
> only. Fixes some segmentation faults when printing array elements
> in Fortran subroutines where array bounds are undefined ie. *.
Two problems with your presentation:
- Changelog entries are what, not why.
* eval.c (evaluate_subexp_standard): Use value_subscript
instead of value_ind.
- You didn't explain how the entire array got allocated and read in.
It's far from obvious, and it's the real problem. It's a bug for
value_ind on a pointer to end up reading in an entire array, I think.
Your patch avoids the issue but doesn't fix it. A few minutes with
valgrind pointed out that the problem is not there but earlier; in the
UNOP_IND resulting from (*x), we allocate a type whose length is
4294967256. That's *x.
You need to either make sure the lengths are fixed earlier, or whatever
is using the length without checking doesn't. In particular, in
allocate_value:
86 val = (struct value *) xmalloc (sizeof (struct value) + TYPE_LENGTH (atype));
Boom, you lose.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer