[SOLVED] GDB internal-error using backtrace

kronmiller · 06-16-2010, 08:48 AM

I have submitted the following to Bugzilla as well.

Thanks in advance for your time and thoughts.

kmk
-----------------------------------------

I have a Fortran routine with a C signal handler. When a signal is caught,
the signal handler calls gdb with a script argument to the system() call to
output a backtrace.

When I build the fortran file with the -g option, run the program, and send it
a signal,I receive the error message “stack.c:295: internal-error …”. Without
the -g option the error message does not appear but as expected I get limited
output in my backtrace.

Below is a description of the environment in which the bug is experienced,
output from gdb showing the bugs occurrence, as well as source code and a
Makefile to reproduce the bug.

The problem occurs in gdb 6.8 but I have seen the same results with gdb 7.1

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

The following lines describe the environment:

gdb -v
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...

gfortran -v
Using built-in specs.
Target i686-pc-linux-gno
Configures with: ./configure --prefix=/usr
Thread model: posix
gcc version 4.4.1 (GCC)

gcc -v
Using built-in specs.
Target i686-pc-linux-gno
Configures with: ./configure --prefix=/usr
Thread model: posix
gcc version 4.4.1 (GCC)

The following is the output from the sample program and gdb when the program
receives signal 10. The signal is sent to the running program with the "kill -
10 pid" command.

ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
./sample.exe: No such file or directory.
Attaching to process 16727
Reading symbols from /home/kronmill/RTRECOVERY/SIMPLE/sample...done.
Reading symbols from /usr/local/lib/libgfortran.so.3...done.
Loaded symbols for /usr/local/lib/libgfortran.so.3
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7c436c0 (LWP 16727)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xb7d19d6e in __waitpid_nocancel () from /lib/libc.so.6
#0 0xb7d19d6e in __waitpid_nocancel () from /lib/libc.so.6
#1 0xb7cb42db in do_system () from /lib/libc.so.6
#2 0x08048891 in handler (
stack.c:295: internal-error: print_frame_args: Assertion `nsym != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
stack.c:295: internal-error: print_frame_args: Assertion `nsym != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727
ZZZZZzzzzzzz 16727

----------------------------------------------
The source files follow:

Code:

C
C     Sample.f
C
      program sample
      implicit none

      integer      ipid 
 
      external handler
 
      call signal(10,handler)                   !Which signal to catch
 
10    ipid = getpid() 
      print *,"ZZZZZzzzzzzz   ",ipid
      call sleep(1)
      go to 10
 
      end

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

Code:

//
// handler.c
//
#include <stdio.h>

void handler (int daSignal) 
{
    char s[100]=" ";

    sprintf(s,"gdb ./sample.exe -x commands.gdb %d", getpid()); 
    system(s);
}

And now the Makefile

Code:

CC = gcc
FC = gfortran
LD = gfortran
INCLUDES = -I.
CFLAGS = -g -O2  $(INCLUDES) 
#
# gdb error using the -g option in FFLAGS
#
FFLAGS =     -fno-underscoring -g
#
# gdb works when not using the -g option in FFLAGS
#
# BUT does not provide full trace information 
#
#FFLAGS =     -fno-underscoring 
LDFLAGS = -g
LIBS = -L/usr/lib/nptl -lm -lc -lgfortran -lpthread
F_SOURCES = \
sample.f 
C_SOURCES = \
handler.c 
F_OBJECTS = $(F_SOURCES:.f=.o)
C_OBJECTS = $(C_SOURCES:.c=.o)
OBJECTS = $(F_OBJECTS) $(C_OBJECTS)
all: sample
sample: $(OBJECTS)
	$(LD) $(LDFLAGS)   -o $@ $(OBJECTS) $(LIBS)
.PHONY: clean
clean:
	-rm -f *.o
	-rm -f *.exe
	-rm -f sample

And here is the commands.gdb file

Code:

bt
detach
quit

------- Additional Comment #1 From Kevin Kronmiller 2010-06-10 13:41 [reply] -------
Here is the output of the same program built on a fro system with gdb 7.1 and
gcc4.4.4.

ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
./sample.exe: No such file or directory.
Attaching to process 3557
Reading symbols from /home/kronmill/RTRECOVERY/SIMPLE/sample...done.
Reading symbols from /usr/lib/libgfortran.so.3...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libgfortran.so.3
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/lib/libgcc_s.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
0xb76486ce in __waitpid_nocancel () from /lib/libc.so.6
#0 0xb76486ce in __waitpid_nocancel () from /lib/libc.so.6
#1 0xb75e3363 in do_system () from /lib/libc.so.6
#2 0x08048857 in handler (
stack.c:289: internal-error: print_frame_args: Assertion `nsym != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
stack.c:289: internal-error: print_frame_args: Assertion `nsym != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557
ZZZZZzzzzzzz 3557

kronmiller · 06-21-2010, 07:53 AM

I have not had any nibbles either here or on Bugzilla yet.

Can anyone comfirm this behavior on their installation? The code, makefile, and output are all included below.

thanks in advance,
kmk

ntubski · 06-21-2010, 09:10 AM

Quote:

Originally Posted by kronmiller

Can anyone comfirm this behavior on their installation? The code, makefile, and output are all included below.

It would help if you put these in [code][/code] tags, especially the Makefile, where whitespace is significant.

The fortran code wouldn't compile, I don't know fortran so I have no idea what these errors mean...

Code:

gfortran -fno-underscoring -g  -c -o sample.o sample.f
sample.f:5.1:

program sample                                                          
 1
Error: Non-numeric character in statement label at (1)
sample.f:5.1:

program sample                                                          
 1
Error: Unclassifiable statement at (1)
sample.f:6.1:

implicit none                                                           
 1
Error: Non-numeric character in statement label at (1)
sample.f:6.1:

implicit none                                                           
 1
Error: Unclassifiable statement at (1)
sample.f:8.1:

integer ipid                                                            
 1
Error: Non-numeric character in statement label at (1)
sample.f:8.1:

integer ipid                                                            
 1
Error: Unclassifiable statement at (1)
sample.f:10.1:

external handler                                                        
 1
Error: Non-numeric character in statement label at (1)
sample.f:10.1:

external handler                                                        
 1
Error: Unclassifiable statement at (1)
sample.f:14.4:

10 ipid = getpid()                                                      
    1
Error: Non-numeric character in statement label at (1)
sample.f:15.1:

print *,"ZZZZZzzzzzzz ",ipid                                            
 1
Error: Non-numeric character in statement label at (1)
sample.f:15.1:

print *,"ZZZZZzzzzzzz ",ipid                                            
 1
Error: Unclassifiable statement at (1)
sample.f:17.1:

go to 10                                                                
 1
Error: Non-numeric character in statement label at (1)
sample.f:17.1:

go to 10                                                                
 1
Error: Unclassifiable statement at (1)
sample.f:19.1:

end                                                                     
 1
Error: Non-numeric character in statement label at (1)
sample.f:19.1:

end                                                                     
 1
Error: Unclassifiable statement at (1)
Error: Unexpected end of file in 'sample.f'
make: *** [sample.o] Error 1

kronmiller · 06-25-2010, 06:14 AM

ntbuski,

Thanks for helping with my problem. I really appreciate your efforts and SI apologize for not responding sooner. I have been out of the office and away from my systems.

Now, to answer your questions....

Fortran expects the code to begin in column 7, not column 1. That looks like what caused your errors.

One exception is statements with labels such as:

10 ipid = getpid()

The "10" goes in column 1 and 2 while the "ipid" starts in 7. Also, a character in column 6 indicates that the line is a comment.

The code should look like this (assuming my spaces are not removed).

Code:

      C
      C Sample.f
      C
       program sample
       implicit none

       integer ipid 

       external handler

       call signal(10,handler) !Which signal to catch

   10 ipid = getpid() 
      print *,"ZZZZZzzzzzzz ",ipid
      call sleep(1)
      go to 10

      end

Again, Thanks for your help,
kmk

ntubski · 06-25-2010, 04:07 PM

Okay, it compiles and runs but I don't have commands.gdb.

signal(2)

Quote:

The routine handler must be very careful, since processing elsewhere was interrupted at some arbitrary point. POSIX has the concept of "safe function". If a signal interrupts an unsafe function, and handler calls an unsafe function, then the behavior is undefined. Safe functions are listed explicitly in the various standards.

system() is definitely not one of the "safe functions", so probably this program has undefined behaviour.

kronmiller · 06-28-2010, 05:51 AM

ntubski,

I have added the commands.gdb file to the main post and here.

Code:

bt
detach
quit

I tend to agree with your safe and unsafe determination for the system() call. I will dig deeper into safe function and see if maybe i fork() call would be better. The other thing that bothers me is that if both "sample" routine and the "handler" are written in FORTRAN, things work well except that it is quite difficult getting the signal number that caused interrept. This is due to the call be value and call be reference differences between FORTRAN and C.

Again, thanks for your time and efforts.

kmk

ntubski · 06-28-2010, 09:40 AM

Okay, it crashes here too. Using fork() and exec() works:

Code:

//
// handler.c
//
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

void handler (int daSignal)
{
    char num[100]=" ";
    sprintf(num, "%d", getpid());

    int pid = fork();
    if (pid > 0) {
        return;                 /* parent */
    } else if (pid == 0) {
        /* child */
        char *const argv[] = { "gdb", "-x", "commands.gdb", "sample", num };

        execve("/usr/bin/gdb", argv, NULL);
    }

    /* error */
    exit(1);
}

Quote:

The other thing that bothers me is that if both "sample" routine and the "handler" are written in FORTRAN, things work well except that it is quite difficult getting the signal number that caused interrept.

But since you did

Code:

call signal(10,handler) !Which signal to catch

it will always be signal number 10, no?

kronmiller · 06-28-2010, 12:56 PM

In the simple example yes, all I will get is 10.

In the "real world" I want to catch say 10, 11, 12,, and 13 with the same handler. Now I need to know which one I got.

I will drop in your fork and exec example this afternoon.

Thanks for the example.

kmk

kronmiller · 06-29-2010, 09:54 AM

I coded up the fork and exec implementation and I still get the following error message and output when using the -g flag for the Fortran source file in the Makefile

Code:

stack.c:289: internal-error: print_frame_args: Assertion `nsym != NULL' failed.

when the -g option is used (FFLAGS) for the Fortran module in the Makefile

Code:

 
CC = gcc
FC = gfortran
LD = gfortran
INCLUDES = -I.
CFLAGS = -g -O2  $(INCLUDES) 
#
# gdb error using the -g option in FFLAGS
#
FFLAGS =     -fno-underscoring -g
#
# gdb works when not using the -g option in FFLAGS
#
# BUT does not provide full trace information 
#
#FFLAGS =     -fno-underscoring 
LDFLAGS = -g
LIBS = -L/usr/lib/nptl -lm -lc -lgfortran -lpthread
F_SOURCES = \
sample.f 
C_SOURCES = \
handler.c 
F_OBJECTS = $(F_SOURCES:.f=.o)
C_OBJECTS = $(C_SOURCES:.c=.o)
OBJECTS = $(F_OBJECTS) $(C_OBJECTS)
all: sample
sample: $(OBJECTS)
	$(LD) $(LDFLAGS)   -o $@ $(OBJECTS) $(LIBS)
.PHONY: clean
clean:
	-rm -f *.o
	-rm -f *.exe
	-rm -f sample

In summary

Code:

FFLAGS =     -fno-underscoring -g

Gives gdb stack error message

Code:

FFLAGS =     -fno-underscoring

Does not generate error message but does not give full information on backtrace

Here is the output when -g is included in FFLAGS

Code:

./sample
 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388
/proc/10388/cmdline
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
Attaching to program: /home/kronmill/RTRECOVERY/SIMPLE/sample, process 10388
Reading symbols from /usr/local/lib/libgfortran.so.3...done.
Loaded symbols for /usr/local/lib/libgfortran.so.3
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d396c0 (LWP 10388)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xb7e0fd6e in __waitpid_nocancel () from /lib/libc.so.6
#0  0xb7e0fd6e in __waitpid_nocancel () from /lib/libc.so.6
#1  0x08048af8 in sighdlr (
stack.c:295: internal-error: print_frame_args: Assertion `nsym != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
stack.c:295: internal-error: print_frame_args: Assertion `nsym != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]

SIGNAL 10 CAUGHT ... SEE STACK TRACE FOR DETAILS

 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388
 ZZZZZzzzzzzz          10388

ntubski · 07-02-2010, 09:10 PM

Hmm, I don't get any crashes,

Code:

GNU gdb (GDB) 7.0.1-debian
GNU Fortran (Debian 4.4.4-5) 4.4.4
gcc (Debian 4.4.4-5) 4.4.4

Code:

% make                                                                ~/tmp/gdb-err
gfortran -fno-underscoring -g
  -c -o sample.o sample.f
gcc -g -O2  -I. -Wall -Wextra   -c -o handler.o handler.c
gfortran -g   -o sample sample.o handler.o -L/usr/lib/nptl -lm -lc -lgfortran -lpthread
% ./sample                                                            ~/tmp/gdb-err
 ZZZZZzzzzzzz          22419
 ZZZZZzzzzzzz          22419
 ZZZZZzzzzzzz          22419
 ZZZZZzzzzzzz          22419
 ZZZZZzzzzzzz          22419
 ZZZZZzzzzzzz          22419
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
sample.exe: No such file or directory.
Attaching to process 22419
Reading symbols from /home/npostavs/tmp/gdb-err/sample...done.
Reading symbols from /usr/lib/libgfortran.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgfortran.so.3
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007f90a3465790 in nanosleep () from /lib/libc.so.6
#0  0x00007f90a3465790 in nanosleep () from /lib/libc.so.6
#1  0x00007f90a3465620 in sleep () from /lib/libc.so.6
#2  0x0000000000400b4e in sample () at sample.f:15
#3  0x0000000000400c3a in main ()
#4  0x00007f90a33e3c4d in __libc_start_main () from /lib/libc.so.6
#5  0x00000000004009c9 in _start ()
 ZZZZZzzzzzzz          22419
 ZZZZZzzzzzzz          22419
^C

Quote:

In the "real world" I want to catch say 10, 11, 12,, and 13 with the same handler. Now I need to know which one I got.

You could have a handler for each number that just dispatches to the real handler with an arg telling which one you got. Although I don't follow why fortran argument handling prevents you from getting this information directly; from what I've seen of fortran here it's looking like a pretty bad language!

kronmiller · 08-03-2010, 10:50 AM

I think the problem is mixing FORTRAN with C and their calling interface differences. Call by value vs Call by address.

Thanks for your help and I will mark this thread as solved.

Kevin K