Program terminated with SIGSEGV when trying to print an array element

Program terminated with SIGSEGV when trying to print an array element

[Wu Zhou]

This is a fortran program.  It runs ok without GDB's control.  But it 
terminated with SIGSEGV when running under GDB.  This happened when I
am trying to print an array element in the sub-function.

The testcase is as follows:
============================
        dimension a(10)
        write(*,*)'This is a test.'
        call sub(a,10)
        write(*,*) a
        stop
        end

        subroutine sub(a,n)
        dimension a(n)
        do 100 i=1, 10
          a(i)=i
100     continue
        return
        end
        
The failing GDB session is as follows:
=======================================
# gdb -q ./array
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b array.f:11
Breakpoint 1 at 0x8048783: file array.f, line 11.
(gdb) r
Starting program: /root/array 
 This is a test.

Breakpoint 1, sub_ (a=0xbf8b9b50, n=@0x804888c) at array.f:11
11                a(i)=i
Current language:  auto; currently fortran
(gdb) p a(1)

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
The program being debugged stopped while in a function called from GDB.
When the function (at 0xbf8b9b50) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).

Re: Program terminated with SIGSEGV when trying to print an array element

[Wu Zhou]

On Tue, 7 Jun 2005, Wu Zhou wrote:

> (gdb) p a(1)
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> The program being debugged stopped while in a function called from GDB.
> When the function (at 0xbf8b9b50) is done executing, GDB will silently
> stop (instead of continuing to evaluate the expression containing
> the function call).

I am doing some debugging on this.  It seems that GDB take a(1) as a 
function.  But in fact that function doesn't exist at all.

The related code is in function evaluate_subexp_standard (in eval.c).  The
opcode of "a(1)" is OP_F77_UNDETERMINED_ARGLIST at the parse time, and its
real type need to be determined at run time: 

    case OP_F77_UNDETERMINED_ARGLIST:

      /* Remember that in F77, functions, substring ops and 
         array subscript operations cannot be disambiguated 
         at parse time.  We have made all array subscript operations, 
         substring operations as well as function calls  come here 
         and we now have to discover what the heck this thing actually was.  
         If it is a function, we process just as if we got an OP_FUNCALL. */

      nargs = longest_to_int (exp->elts[pc + 1].longconst);
      (*pos) += 2;

      /* First determine the type code we are dealing with.  */
      arg1 = evaluate_subexp (NULL_TYPE, exp, pos, noside);
      type = check_typedef (value_type (arg1));
      code = TYPE_CODE (type);

      switch (code)
	{
	case TYPE_CODE_ARRAY:
	  goto multi_f77_subscript;

	case TYPE_CODE_STRING:
	  goto op_f77_substr;

	case TYPE_CODE_PTR:
	case TYPE_CODE_FUNC:
	  /* It's a function call. */
	  /* Allocate arg vector, including space for the function to be
	     called in argvec[0] and a terminating NULL */
	  argvec = (struct value **) alloca (sizeof (struct value *) * (nargs + 2));
	  argvec[0] = arg1;
	  tem = 1;
	  for (; tem <= nargs; tem++)
	    argvec[tem] = evaluate_subexp_with_coercion (exp, pos, noside);

As far as I can see, the problem lies in that GDB take TYPE_CODE_PTR as
a function call as well.  But in the above failing testcase, "a" is a 
pointer to array type (Fortran treat formal parameter as pointer). Its 
code is TYPE_CODE_PTR indeed, but it is not a function call.  

So maybe we need to change the code logic above.  My thought is when the
code match TYPE_CODE_PTR, we first get its target_type.  If it is 
TYPE_CODE_ARRAY, we can goto multi_f77_subscript. If not, we can go on 
with the orignial path.  But I have one question on the original code: 
in which circumstance should a function's code return TYPE_CODE_PTR,
isn't the code of a function always return TYPE_CODE_FUNC? 

Any thought on this?  Any suggestions and comments are highly appreciated! 

Cheers
- Wu Zhou

Re: Program terminated with SIGSEGV when trying to print an array element

[Daniel Jacobowitz]

On Tue, Jun 07, 2005 at 04:58:10PM +0800, Wu Zhou wrote:
> As far as I can see, the problem lies in that GDB take TYPE_CODE_PTR as
> a function call as well.  But in the above failing testcase, "a" is a 
> pointer to array type (Fortran treat formal parameter as pointer). Its 
> code is TYPE_CODE_PTR indeed, but it is not a function call.  
> 
> So maybe we need to change the code logic above.  My thought is when the
> code match TYPE_CODE_PTR, we first get its target_type.  If it is 
> TYPE_CODE_ARRAY, we can goto multi_f77_subscript. If not, we can go on 
> with the orignial path.  But I have one question on the original code: 
> in which circumstance should a function's code return TYPE_CODE_PTR,
> isn't the code of a function always return TYPE_CODE_FUNC? 
> 
> Any thought on this?  Any suggestions and comments are highly appreciated! 

You didn't mention what Fortran compiler was being used.  Probably,
whichever one it was, it generates debug information that GDB is not
expecting.

It sounds like you're right; we should be checking the target type of
the pointer.  Can we end up with a pointer to a string, too?

I'm afraid I don't know the answer to your other question.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Program terminated with SIGSEGV when trying to print an array element

[Wu Zhou]

On Tue, 7 Jun 2005, Daniel Jacobowitz wrote:

> On Tue, Jun 07, 2005 at 04:58:10PM +0800, Wu Zhou wrote:
> > As far as I can see, the problem lies in that GDB take TYPE_CODE_PTR as
> > a function call as well.  But in the above failing testcase, "a" is a 
> > pointer to array type (Fortran treat formal parameter as pointer). Its 
> > code is TYPE_CODE_PTR indeed, but it is not a function call.  
> > 
> > So maybe we need to change the code logic above.  My thought is when the
> > code match TYPE_CODE_PTR, we first get its target_type.  If it is 
> > TYPE_CODE_ARRAY, we can goto multi_f77_subscript. If not, we can go on 
> > with the orignial path.  But I have one question on the original code: 
> > in which circumstance should a function's code return TYPE_CODE_PTR,
> > isn't the code of a function always return TYPE_CODE_FUNC? 
> > 
> > Any thought on this?  Any suggestions and comments are highly appreciated! 
> 
> You didn't mention what Fortran compiler was being used.  Probably,
> whichever one it was, it generates debug information that GDB is not
> expecting.

I used g77-3.3.3 on PPC64, and gfortran-4.0.0 on Fedora 4 test 3 on i386.  
Both failed (Illegal instruction on PPC64 and SEGV error on i386).  I had 
some look at the related debuginfo (array "a"), it is indeed an pointer 
to array on both platform. 

> It sounds like you're right; we should be checking the target type of
> the pointer.  Can we end up with a pointer to a string, too?

Sure.  But now I am having difficulty in one problem: given an struct value 
with the type being TYPE_CODE_PTR, how to get the value of the array (or 
string or whatever) it refer to?  We need to know this to go on with the 
following evaluation.  I had thought that function "value_from_pointer" 
will do this, but it turn out to be false.  Anyone could help on this? 

Thanks in advance.

Cheers
- Wu Zhou

Re: Program terminated with SIGSEGV when trying to print an array element

[Daniel Jacobowitz]

On Wed, Jun 08, 2005 at 02:52:20PM +0800, Wu Zhou wrote:
> Sure.  But now I am having difficulty in one problem: given an struct value 
> with the type being TYPE_CODE_PTR, how to get the value of the array (or 
> string or whatever) it refer to?  We need to know this to go on with the 
> following evaluation.  I had thought that function "value_from_pointer" 
> will do this, but it turn out to be false.  Anyone could help on this? 

Usually, value_ind.  Do you have a pointer to a TYPE_CODE_ARRAY, or has
the array decayed into a pointer (like in C)?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Program terminated with SIGSEGV when trying to print an array element

[Wu Zhou]

On Wed, 8 Jun 2005, Daniel Jacobowitz wrote:

> On Wed, Jun 08, 2005 at 02:52:20PM +0800, Wu Zhou wrote:
> > Sure.  But now I am having difficulty in one problem: given an struct value 
> > with the type being TYPE_CODE_PTR, how to get the value of the array (or 
> > string or whatever) it refer to?  We need to know this to go on with the 
> > following evaluation.  I had thought that function "value_from_pointer" 
> > will do this, but it turn out to be false.  Anyone could help on this? 
> 
> Usually, value_ind.  Do you have a pointer to a TYPE_CODE_ARRAY, or has
> the array decayed into a pointer (like in C)?

Thank you, Daniel! "value_ind" worked.  I will clean up a patch for this 
later and send to gdb-patches for review.  

BTW, to answer your question, what I have is a pointer to a value with the
type being TYPE_CODE_ARRAY.  It is not like that in C.

Cheers
- Wu Zhou