gdb 6.3 segfault at stack.c:294

gdb 6.3 segfault at stack.c:294

[Joost VandeVondele]

Hi,

trying to debug a segfault in my program, gdb segfaults as well. I'm 
wondering if this is a known issue. This is what I'm using:

GNU gdb 6.3
configured as "i686-pc-linux-gnu"
uname -a
Linux vinegar 2.6.8-24.11-smp #1 SMP Fri Jan 14 13:01:26 UTC 2005 i686 
i686 i386 GNU/Linux
gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada 
--disable-checking --libdir=/usr/lib --enable-libgcj 
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.4 (pre 3.3.5 20040809)

The executable is a fortran based one, compiled using NAG's f95 
(which uses gcc to generate code AFAIK).

The only real info I have right now is what I get running gdb through gdb 
on the segfaulting executable:

------------------------------------------
QS/regtest> gdb gdb
GNU gdb 6.3
Copyright 2004 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 "i686-pc-linux-gnu"...Using host libthread_db 
library "/lib/tls/libthread_db.so.1".

(gdb) run ../../../exe/Linux-i686-nag/cp2k.sdbg
Starting program: /home/vondele/bin/gdb 
../../../exe/Linux-i686-nag/cp2k.sdbg
GNU gdb 6.3
Copyright 2004 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 "i686-pc-linux-gnu"...Using host libthread_db 
library "/lib/tls/libthread_db.so.1".

(gdb) c
The program is not being run.
(gdb) run
Starting program: /data1/vondele/dev/cp2k/exe/Linux-i686-nag/cp2k.sdbg
Detaching after fork from child process 31218.
Detaching after fork from child process 31230.
  @ has created process number                                        0 
0

   **** **** ******  **  PROGRAM STARTED AT                   20050606 
141655.015
  ***** ** ***  *** **   PROGRAM STARTED ON
  **    ****   ******    PROGRAM STARTED BY
  ***** **    ** ** **   PROGRAM PROCESS ID 
0
   **** **  *******  **  PROGRAM STARTED IN 
./

  CP2K| Program compiled at                          Mon Jun  6 09:09:00 
BST 2005
  CP2K| Program compiled on 
vinegar
  CP2K| Program compiled for 
Linux-i686-nag
  CP2K| Last CVS entry            message_passing.F/1.50/Mon Jun  6 
06:44:18 2005

  ===== Routine Calling Stack =====

             1 CP2K

Program received signal SIGSEGV, Segmentation fault.
0x0917ad8d in input_section_types_MP_section_vals_add_values 
(section_vals_=0x4088b138,

_input_section_types_section_vals_add_values_section_vals_map_=0x4088b13c, 
error_=0xbfffa150,

Program received signal SIGSEGV, Segmentation fault.
print_frame_args (func=Variable "func" is not available.
) at stack.c:294
294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
(gdb) list
289                 {
290                   struct symbol *nsym;
291                   nsym = lookup_symbol
292                     (DEPRECATED_SYMBOL_NAME (sym),
293                      b, VAR_DOMAIN, (int *) NULL, (struct symtab **) 
NULL);
294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
295                     {
296                       /* There is a LOC_ARG/LOC_REGISTER pair.  This 
means that
297                          it was passed on the stack and loaded into a 
register,
298                          or passed in a register and stored in a stack 
slot.

------------------------------------------

I can provide the executable that causes this, but it's quite large 
(122Mb). I can also try to get some more info locally first, but I'm not a 
very experienced gdb user.

Thanks in advance,

Joost

Re: gdb 6.3 segfault at stack.c:294

[Vincent Rubiolo]

Hello,

Something that the gdb maintaniers would welcome is a stack trace of the 
faulting gdb. To do that, rebuild gdb with debugging enabled (very easy, 
juste download, configure and make/make install) and when it crashes, 
issue the following at the other gdb prompt:
(gdb) bt

This will give more information on the faulty piece of code to the 
developers.

HTH,

Vincent

Joost VandeVondele wrote:
> Hi,
> 
> trying to debug a segfault in my program, gdb segfaults as well. I'm 
> wondering if this is a known issue. This is what I'm using:
> 
> GNU gdb 6.3
> configured as "i686-pc-linux-gnu"
> uname -a
> Linux vinegar 2.6.8-24.11-smp #1 SMP Fri Jan 14 13:01:26 UTC 2005 i686 
> i686 i386 GNU/Linux
> gcc -v
> Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
> Configured with: ../configure --enable-threads=posix --prefix=/usr 
> --with-local-prefix=/usr/local --infodir=/usr/share/info 
> --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada 
> --disable-checking --libdir=/usr/lib --enable-libgcj 
> --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
> --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
> Thread model: posix
> gcc version 3.3.4 (pre 3.3.5 20040809)
> 
> The executable is a fortran based one, compiled using NAG's f95 (which 
> uses gcc to generate code AFAIK).
> 
> The only real info I have right now is what I get running gdb through 
> gdb on the segfaulting executable:
> 
> ------------------------------------------
> QS/regtest> gdb gdb
> GNU gdb 6.3
> Copyright 2004 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 "i686-pc-linux-gnu"...Using host libthread_db 
> library "/lib/tls/libthread_db.so.1".
> 
> (gdb) run ../../../exe/Linux-i686-nag/cp2k.sdbg
> Starting program: /home/vondele/bin/gdb 
> ../../../exe/Linux-i686-nag/cp2k.sdbg
> GNU gdb 6.3
> Copyright 2004 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 "i686-pc-linux-gnu"...Using host libthread_db 
> library "/lib/tls/libthread_db.so.1".
> 
> (gdb) c
> The program is not being run.
> (gdb) run
> Starting program: /data1/vondele/dev/cp2k/exe/Linux-i686-nag/cp2k.sdbg
> Detaching after fork from child process 31218.
> Detaching after fork from child process 31230.
>  @ has created process number                                        0 0
> 
>   **** **** ******  **  PROGRAM STARTED AT                   20050606 
> 141655.015
>  ***** ** ***  *** **   PROGRAM STARTED ON
>  **    ****   ******    PROGRAM STARTED BY
>  ***** **    ** ** **   PROGRAM PROCESS ID 0
>   **** **  *******  **  PROGRAM STARTED IN ./
> 
>  CP2K| Program compiled at                          Mon Jun  6 09:09:00 
> BST 2005
>  CP2K| Program compiled on vinegar
>  CP2K| Program compiled for Linux-i686-nag
>  CP2K| Last CVS entry            message_passing.F/1.50/Mon Jun  6 
> 06:44:18 2005
> 
>  ===== Routine Calling Stack =====
> 
>             1 CP2K
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0917ad8d in input_section_types_MP_section_vals_add_values 
> (section_vals_=0x4088b138,
> 
> _input_section_types_section_vals_add_values_section_vals_map_=0x4088b13c, 
> error_=0xbfffa150,
> 
> Program received signal SIGSEGV, Segmentation fault.
> print_frame_args (func=Variable "func" is not available.
> ) at stack.c:294
> 294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
> (gdb) list
> 289                 {
> 290                   struct symbol *nsym;
> 291                   nsym = lookup_symbol
> 292                     (DEPRECATED_SYMBOL_NAME (sym),
> 293                      b, VAR_DOMAIN, (int *) NULL, (struct symtab **) 
> NULL);
> 294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
> 295                     {
> 296                       /* There is a LOC_ARG/LOC_REGISTER pair.  This 
> means that
> 297                          it was passed on the stack and loaded into 
> a register,
> 298                          or passed in a register and stored in a 
> stack slot.
> 
> ------------------------------------------
> 
> I can provide the executable that causes this, but it's quite large 
> (122Mb). I can also try to get some more info locally first, but I'm not 
> a very experienced gdb user.
> 
> Thanks in advance,
> 
> Joost

-- 
Using Firefox and Thunderbird at Wind River:
http://twiki.wrs.com/do/view/ENGtools/MozillaAtWindriver

Re: gdb 6.3 segfault at stack.c:294

[Joost VandeVondele]

That's what I get:

(gdb) bt
#0  print_frame_args (func=Variable "func" is not available.
) at stack.c:294
#1  0x08110cd5 in print_args_stub (args=0xbfffdba4) at stack.c:402
#2  0x08084d81 in do_catch_errors (uiout=0x82e37e0, data=0x0) at top.c:524
#3  0x08084beb in catcher (func=0x8084d70 <do_catch_errors>, 
func_uiout=0x82e37e0, func_args=0xbfffdac8, func_val=0xbfffdad4,
     func_caught=0xbfffdad0, errstring=0x82154f0 "", gdberrmsg=0x0, mask=6) 
at top.c:431
#4  0x08084dd6 in catch_errors (func=0, func_args=0x0, errstring=0x0, 
mask=0) at top.c:536
#5  0x081114f6 in print_frame_info (fi=0x82d2850, print_level=0, 
print_what=SRC_AND_LOC, print_args=1) at stack.c:654
#6  0x081116a8 in print_stack_frame_stub (args=0x0) at stack.c:135
#7  0x08084d81 in do_catch_errors (uiout=0x82e37e0, data=0x0) at top.c:524
#8  0x08084beb in catcher (func=0x8084d70 <do_catch_errors>, 
func_uiout=0x82e37e0, func_args=0xbfffdcf8, func_val=0xbfffdd04,
     func_caught=0xbfffdd00, errstring=0x82154f0 "", gdberrmsg=0x0, mask=6) 
at top.c:431
#9  0x08084dd6 in catch_errors (func=0, func_args=0x0, errstring=0x0, 
mask=0) at top.c:536
#10 0x08110844 in print_stack_frame (fi=0x0, print_level=0, 
print_what=LOCATION) at stack.c:156
#11 0x0810ac1b in normal_stop () at infrun.c:3017
#12 0x0810d69b in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, 
step=0) at infrun.c:815
#13 0x08107450 in run_command (args=0x0, from_tty=1) at infcmd.c:481
#14 0x080851d0 in execute_command (p=0x82aeedb "", from_tty=1) at 
top.c:733
#15 0x08118044 in command_handler (command=0x82aeed8 "") at 
event-top.c:500
#16 0x081184e5 in command_line_handler (rl=0x83e06f0 "8~2\b") at 
event-top.c:793
#17 0x081fdf70 in rl_callback_read_char () at callback.c:123
#18 0x081179cb in rl_callback_read_char_wrapper (client_data=0x0) at 
event-top.c:166
#19 0x08117257 in handle_file_event (event_file_desc=0) at 
event-loop.c:721
#20 0x08116cf4 in process_event () at event-loop.c:334
#21 0x08117590 in gdb_do_one_event (data=0x0) at event-loop.c:371
#22 0x08084d81 in do_catch_errors (uiout=0x82e37e0, data=0x0) at top.c:524
#23 0x08084beb in catcher (func=0x8084d70 <do_catch_errors>, 
func_uiout=0x82e37e0, func_args=0xbfffe098, func_val=0xbfffe0a4,
     func_caught=0xbfffe0a0, errstring=0x82154f0 "", gdberrmsg=0x0, mask=6) 
at top.c:431
#24 0x08084dd6 in catch_errors (func=0, func_args=0x0, errstring=0x0, 
mask=0) at top.c:536
#25 0x080c50f4 in tui_command_loop (data=0x0) at ./tui/tui-interp.c:150
#26 0x08114b7f in current_interp_command_loop () at interps.c:277
#27 0x0807ae8b in captured_command_loop (data=0x0) at ./main.c:91
#28 0x08084d81 in do_catch_errors (uiout=0x82e37e0, data=0x0) at top.c:524
#29 0x08084beb in catcher (func=0x8084d70 <do_catch_errors>, 
func_uiout=0x82e37e0, func_args=0xbfffe208, func_val=0xbfffe214,
     func_caught=0xbfffe210, errstring=0x82154f0 "", gdberrmsg=0x0, mask=6) 
at top.c:431
#30 0x08084dd6 in catch_errors (func=0, func_args=0x0, errstring=0x0, 
mask=0) at top.c:536
#31 0x0807b5f4 in captured_main (data=0x0) at ./main.c:801
#32 0x08084d81 in do_catch_errors (uiout=0x828cf40, data=0x0) at top.c:524
#33 0x08084beb in catcher (func=0x8084d70 <do_catch_errors>, 
func_uiout=0x828cf40, func_args=0xbfffe488, func_val=0xbfffe494,
     func_caught=0xbfffe490, errstring=0x82154f0 "", gdberrmsg=0x0, mask=6) 
at top.c:431
#34 0x08084dd6 in catch_errors (func=0, func_args=0x0, errstring=0x0, 
mask=0) at top.c:536
#35 0x0807aef3 in gdb_main (args=0x0) at ./main.c:810
#36 0x0807ae71 in main (argc=0, argv=0x0) at gdb.c:35

Re: gdb 6.3 segfault at stack.c:294

[Daniel Jacobowitz]

On Mon, Jun 06, 2005 at 02:44:05PM +0100, Joost VandeVondele wrote:
> The executable is a fortran based one, compiled using NAG's f95 
> (which uses gcc to generate code AFAIK).

GDB is not tested using this compiler; if it generates its own debug
information, it's probably in some way incompatible with GDB.

> Program received signal SIGSEGV, Segmentation fault.
> print_frame_args (func=Variable "func" is not available.
> ) at stack.c:294
> 294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
> (gdb) list
> 289                 {
> 290                   struct symbol *nsym;
> 291                   nsym = lookup_symbol
> 292                     (DEPRECATED_SYMBOL_NAME (sym),
> 293                      b, VAR_DOMAIN, (int *) NULL, (struct symtab **) 
> NULL);
> 294                   if (SYMBOL_CLASS (nsym) == LOC_REGISTER)
> 295                     {
> 296                       /* There is a LOC_ARG/LOC_REGISTER pair.  This 
> means that
> 297                          it was passed on the stack and loaded into a 
> register,
> 298                          or passed in a register and stored in a stack 
> slot.

Presumably nsym is NULL.  I can't imagine how that happened.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb 6.3 segfault at stack.c:294

[Joost VandeVondele]

> On Mon, Jun 06, 2005 at 02:44:05PM +0100, Joost VandeVondele wrote:
>> The executable is a fortran based one, compiled using NAG's f95
>> (which uses gcc to generate code AFAIK).
>
> GDB is not tested using this compiler; if it generates its own debug
> information, it's probably in some way incompatible with GDB.
>

This could possibly be, I have no idea how it is (mis?)using gcc ..
>
> Presumably nsym is NULL.  I can't imagine how that happened.
>

I think this is right :

(gdb) print nsym
$1 = (struct symbol *) 0x0