Re: GDB segmentation fault

["Peter.Schauer" <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>]

Here is a fix for the GDB core dump. Any objections ?

PS: To examine the array elements, you have to use
    `print (*c)(1)@__g77_length_c'.

	* gdbtypes.c (create_array_type):  Avoid core dump if high_bound
	is below low_bound. Set BOUND_CANNOT_BE_DETERMINED if it is a
	variable length array.
	(check_typedef):  Ditto.

*** gdb-4.17/gdb/gdbtypes.c.orig	Tue Feb 17 23:51:46 1998
--- gdb-4.17/gdb/gdbtypes.c	Mon Jun 29 11:19:17 1998
***************
*** 442,447 ****
--- 442,453 ----
    CHECK_TYPEDEF (element_type);
    TYPE_LENGTH (result_type) =
      TYPE_LENGTH (element_type) * (high_bound - low_bound + 1);
+   if (low_bound > high_bound)
+     {
+       TYPE_LENGTH (result_type) = 0;
+       if (high_bound == -1)
+ 	TYPE_ARRAY_UPPER_BOUND_TYPE(result_type) = BOUND_CANNOT_BE_DETERMINED;
+     }
    TYPE_NFIELDS (result_type) = 1;
    TYPE_FIELDS (result_type) =
      (struct field *) TYPE_ALLOC (result_type, sizeof (struct field));
***************
*** 996,1008 ****
  	       && (TYPE_CODE (range_type = TYPE_FIELD_TYPE (type, 0))
  		   == TYPE_CODE_RANGE))
  	{
  	  /* Now recompute the length of the array type, based on its
  	     number of elements and the target type's length.  */
! 	  TYPE_LENGTH (type) =
! 	    ((TYPE_FIELD_BITPOS (range_type, 1)
! 	      - TYPE_FIELD_BITPOS (range_type, 0)
! 	      + 1)
! 	     * TYPE_LENGTH (target_type));
  	  TYPE_FLAGS (type) &= ~TYPE_FLAG_TARGET_STUB;
  	}
        else if (TYPE_CODE (type) == TYPE_CODE_RANGE)
--- 1002,1023 ----
  	       && (TYPE_CODE (range_type = TYPE_FIELD_TYPE (type, 0))
  		   == TYPE_CODE_RANGE))
  	{
+ 	  LONGEST low_bound, high_bound;
+ 
  	  /* Now recompute the length of the array type, based on its
  	     number of elements and the target type's length.  */
! 	  low_bound = TYPE_FIELD_BITPOS (range_type, 0);
! 	  high_bound = TYPE_FIELD_BITPOS (range_type, 1);
! 	  if (low_bound > high_bound)
! 	    {
! 	    TYPE_LENGTH (type) = 0;
! 	    if (high_bound == -1)
! 	      TYPE_ARRAY_UPPER_BOUND_TYPE(type)
! 		= BOUND_CANNOT_BE_DETERMINED;
! 	    }
! 	  else
! 	    TYPE_LENGTH (type) =
! 	      (high_bound - low_bound + 1) * TYPE_LENGTH (target_type);
  	  TYPE_FLAGS (type) &= ~TYPE_FLAG_TARGET_STUB;
  	}
        else if (TYPE_CODE (type) == TYPE_CODE_RANGE)

> Hello,
> 
> Recently, while debugging a Fortran program on Linux (Redhat 5.0 with
> updates) with 'ddd' 2.2.3 the 'ddd' program suddenly died when moving
> the cursor on a character variable declared as 
>       CHARACTER VAR*(*)
> This was perfectly reproducible and I could boil the program down to
> the following code:
> 
>       Program xyz
>       Character c*30
>       c = 'This is only a test'
>       Call sub(c)
>       End
>       
>       Subroutine sub ( c )
>       Character c*(*)      
>       Write(*,*) 'C=''',c,''''
>       Write(*,*) 'LEN(C)=',Len(c)
>       End
> 
> The test program was compiled with 'g77' 0.5.22 ('gcc' 2.7.2.3) and
> its execution was perfectly o.k but displaying variable 'c' in
> subroutine 'sub' was deadly for 'gdb'. Without 'ddd', i.e. directly
> with 'gdb' the 'gdb' segmentation fault can be produced as well:
> Just step into the subroutine and display 'c' or any part of it.
> Inspection of the resulting core dump gives:
> 
> >> gdb /usr/bin/gdb core
> GNU gdb 4.17
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i586-pc-linux-gnu"...
> Core was generated by `gdb -q -fullname ./t'.
> Program terminated with signal 11, Segmentation fault.
> find_solib: Can't read pathname for load map: Input/output error
> 
> #0  0x4006ed43 in ?? () from /lib/libc.so.6
> (gdb) where
> #0  0x4006ed43 in ?? () from /lib/libc.so.6
> #1  0x807937d in child_xfer_memory (memaddr=3221224232, myaddr=0x81cfb80 "({\x7f?8\034\024\b\x7f\x7f\x7f\x7f", len=-1, write=0, 
>     target=0x815521c) at infptrace.c:493
> #2  0x80827a8 in target_xfer_memory (memaddr=3221224232, myaddr=0x81cfb80 "({\x7f?8\034\024\b\x7f\x7f\x7f\x7f", len=-1, 
>     write=0, bfd_section=0x0) at target.c:813
> #3  0x80826bb in target_read_memory_section (memaddr=3221224232, myaddr=0x81cfb80 "({\x7f?8\034\024\b\x7f\x7f\x7f\x7f", len=-1, 
>     bfd_section=0x0) at target.c:723
> #4  0x80ac089 in read_memory_section (memaddr=3221224232, myaddr=0x81cfb80 "({\x7f?8\034\024\b\x7f\x7f\x7f\x7f", len=-1, 
>     bfd_section=0x0) at corefile.c:236
> #5  0x805b3e6 in value_fetch_lazy (val=0x81cfb50) at valops.c:468
> #6  0x80b9bc4 in c_value_print (val=0x81cfb50, stream=0x8141c38, format=0, pretty=Val_pretty_default)
>     at c-valprint.c:470
> #7  0x8060bf4 in value_print (val=0x81cfb50, stream=0x8141c38, format=0, pretty=Val_pretty_default)
>     at valprint.c:184
> #8  0x8061c96 in print_formatted (val=0x81cfb50, format=0, size=-5) at printcmd.c:319
> #9  0x8062abc in output_command (exp=0x8155e9f "*c", from_tty=1) at printcmd.c:938
> #10 0x80c5b00 in execute_command (p=0x8155ea0 "c", from_tty=1) at top.c:1259
> #11 0x80c5ca6 in command_loop () at top.c:1339
> #12 0x80cc6e5 in main (argc=4, argv=0xbffffb90) at main.c:554
> 
> The reason of this core dump might either be a 'gdb' bug or a
> 'g77' bug and it takes 'ddd' down with it (2.2.3 with a notice
> (un-)readable for 0.0001 seconds or so, 3.0 with a prompt asking to
> exit or restart). Therefore, this message is sent to developers of
> all three programs involved and I would appreciate to hear of
> a solution. (I am sorry that I can only present the problem and
> not a fix to it.)
> 
>    Kind regards,
>     Konrad Bernloehr
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>        Dr. Konrad Bernloehr,  Institut fuer Kernphysik III
>      Forschungszentrum Karlsruhe,  76021 Karlsruhe,  Germany
>                    E-mail: bernlohr@ik3.fzk.de
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de