Re: gdb segmentation fault

Re: gdb segmentation fault

[Daniel Micol Ponce]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

Hi,

Here I sent you the typescript file that I generated doing what you told
me. I hope you can find the bug.

Sincerely,

  Daniel Micol Ponce

El mié, 14-01-2004 a las 10:32, Michael Elizabeth Chastain escribió:
> Hello,
> 
> This sounds like a real bug in gdb.
> 
> Can you do this please:
> 
>   Run the "script" command
>   Run "env" so I can see your environment
>     (particularly the locale settings)
>   Do "gdb gdb"
>   Make the bug happen
>   Get a backtrace
>   Exit "script"
> 
> Then mail me the same information that you mailed to bug-gdb,
> along with the whole "typescript" file.
> 
> Send it to:
> 
>   mec.gnu@mindspring.com (my other e-mail address)
>   gdb@sources.redhat.com (the current mailing list)
> 
> I know this is a lot of work to ask of you, but it will help me
> localize the bug.
> 
> Thanks,
> 
> Michael C
> GDB QA Guy

[-- Attachment #2: typescript --]
[-- Type: application/octet-stream, Size: 4731 bytes --]

Re: gdb segmentation fault

[Daniel Jacobowitz]

Judging from the log, this is a bug in the included readline that I've
encountered before (but couldn't figure out at the time).


On Wed, Jan 14, 2004 at 05:45:55PM +0100, Daniel Micol Ponce wrote:
> Hi,
> 
> Here I sent you the typescript file that I generated doing what you told
> me. I hope you can find the bug.
> 
> Sincerely,
> 
>   Daniel Micol Ponce
> 
> El mié, 14-01-2004 a las 10:32, Michael Elizabeth Chastain escribió:
> > Hello,
> > 
> > This sounds like a real bug in gdb.
> > 
> > Can you do this please:
> > 
> >   Run the "script" command
> >   Run "env" so I can see your environment
> >     (particularly the locale settings)
> >   Do "gdb gdb"
> >   Make the bug happen
> >   Get a backtrace
> >   Exit "script"
> > 
> > Then mail me the same information that you mailed to bug-gdb,
> > along with the whole "typescript" file.
> > 
> > Send it to:
> > 
> >   mec.gnu@mindspring.com (my other e-mail address)
> >   gdb@sources.redhat.com (the current mailing list)
> > 
> > I know this is a lot of work to ask of you, but it will help me
> > localize the bug.
> > 
> > Thanks,
> > 
> > Michael C
> > GDB QA Guy



-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb segmentation fault

[Michael Elizabeth Chastain]

Hello,

Thanks for the typescript.

This looks like it may be fixed by some new readline patches
which Elena Zannoni is about to commit.  If possible, would you
be willing to apply these patches to your copy of gdb 6.0,
rebuild gdb 6.0, and try the problem again?

The patches are at:

  http://sources.redhat.com/ml/gdb-patches/2004-01/msg00675.html

Thanks,

Michael C
GDB QA Guy

GDB segmentation fault

[Konrad Bernloehr]

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

Re: GDB segmentation fault

[Peter.Schauer]

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