This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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 "({?8\034\024\b", len=-1, write=0,
> target=0x815521c) at infptrace.c:493
> #2 0x80827a8 in target_xfer_memory (memaddr=3221224232, myaddr=0x81cfb80 "({?8\034\024\b", len=-1,
> write=0, bfd_section=0x0) at target.c:813
> #3 0x80826bb in target_read_memory_section (memaddr=3221224232, myaddr=0x81cfb80 "({?8\034\024\b", len=-1,
> bfd_section=0x0) at target.c:723
> #4 0x80ac089 in read_memory_section (memaddr=3221224232, myaddr=0x81cfb80 "({?8\034\024\b", 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