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