GDB segmentation fault

[Konrad Bernloehr <bernlohr@ik3.fzk.de>]

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