This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Evaluating arrays in Fortran


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]