program x
character(len=1024) :: foo
integer:: ret
foo = 'ls'
call system(foo, ret)
end program
This program crashes with SIGSEGV on ifort.
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
a.out 0000000100000F0B Unknown Unknown Unknown
a.out 0000000100000EAA Unknown Unknown Unknown
a.out 0000000100000E8B Unknown Unknown Unknown
a.out 0000000100000E0C Unknown Unknown Unknown
a.out 0000000100000DA4 Unknown Unknown Unknown
gdb:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x0000000100000f0a in allocCstr ()
(gdb) bt
#0 0x0000000100000f0a in allocCstr ()
#1 0x0000000100000eaa in system_ ()
#2 0x0000000100000e0c in main ()
ifort --version
ifort (IFORT) 11.1 20100806
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
Is this a bug or a feature?
I can reproduce the error that you're seeing if I copy your code (Linux, ifort 11.0 20090131). However, a check of the Intel fortran compiler manual suggests that it's a function rather than a subroutine. If I modify the code to:
program x
character(len=1024) :: foo
integer :: ret
foo = 'ls'
ret = system(foo)
end program x
Then it works successfully.
Well, this works on my machine (ifort, xp sp3)
CHARACTER(LEN=1024) :: FOO
INTEGER :: RET
FOO = 'dir'
CALL SYSTEM(FOO, RET)
READ(*,*)
END
Also with
RET = SYSTEM(FOO)
Also works on the same ifort you're using, xp sp2.
Related
I am trying to debug AVX-512 instructions on an emulated CPU using Intel® Software Development Emulator but it doesn't work as desired after setting a breakpoint. I followed this blog post: Debugging Emulated Code on Linux*
In window #1:
~$ g++ -g -O0 -mavx512f main.cpp -o main # compile main.cpp file
~$ sde -debug -- ./main # enable debugging
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :54105
In window #2
# run debugger
~$ gdb ./main
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
# set target "target remote :portnumber"
(gdb) target remote :54105
Remote debugging using :54105
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fa7bbbcc100 in ?? () from /lib64/ld-linux-x86-64.so.2
# suspend program at main function
(gdb) break main
Breakpoint 1 at 0x2c9c: file /home/borrow/source/repos/se-test/main.cpp, line 165.
# start program execution from the beginning of the program
(gdb) run
The "remote" target does not support "run". Try "help target" or
"continue".
# step to next line of code
(gdb) step
Cannot find bounds of current function
# continue executing until next break point
(gdb) c
Continuing.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
[Inferior 1 (Remote target) exited normally]
In window #2: as you can see
gdb run should run a program but it doesn't work. gdb c should also run until the next breakpoint but executes the program and terminates. This command gives me the following warning message:
warning: Probes-based dynamic linker interface failed.
In window #1: The program runs and ends (without stopping).
Program code looks like this:
// main.cpp
#include <immintrin.h>
const int N=64;
int64_t srcA[N] = {0};
int64_t srcB[N] = {0};
int64_t dst[N] = {0};
void foo()
{
__m512i result,B,C;
for ( int i=0; i<N; i+=8 ){
B = _mm512_loadu_si512(&srcA[i]);
C = _mm512_loadu_si512(&srcB[i]);
result = _mm512_add_epi64(B,C);
_mm512_storeu_si512(&dst[i], result);
}
}
int main() {
...
foo();
...
}
I tried running AVX2 code without SDE emulator using gdb and it worked. First I start it on an emulated CPU with SDE, it fails. How can I solve this problem?
It seems to be broken for PIE executables
(confirmed on Arch GNU/Linux with GCC 10.2, GDB 10.1, SDE 8.33.)
Build with g++ -O2 -fno-pie -no-pie -g -march=skylake-avx512 and everything works. (I had to run gdb ./a.out instead of bare GDB; without that it couldn't find the right file even after connecting to the remote.)
$ g++ -O2 -march=skylake-avx512 -no-pie -fno-pie -g avx512.cpp
$ /opt/sde-external-8.33.0-2019-02-07-lin/sde64 -debug -- ./a.out
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :59783
Then in another terminal tab
$ gdb ./a.out
...
(gdb) target remote :59783
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f4f7033b090 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x401050: file avx512.cpp, line 29.
(gdb) b foo
Breakpoint 2 at 0x401190: file avx512.cpp, line 14.
(gdb) c
Continuing.
Breakpoint 1, main () at avx512.cpp:23
(gdb) layout asm
(copy-paste of some of the disassembly window)
│B+ 0x401120 <_Z3foov> xor eax,eax
│ 0x401122 <_Z3foov+2> nop WORD PTR [rax+rax*1+0x0]
│ >0x401128 <_Z3foov+8> vmovdqu64 zmm1,ZMMWORD PTR [rax+0x404260]
│ 0x401132 <_Z3foov+18> add rax,0x40
│ 0x401136 <_Z3foov+22> vpaddq zmm0,zmm1,ZMMWORD PTR [rax+0x404420]
│ 0x401140 <_Z3foov+32> vmovdqu64 ZMMWORD PTR [rax+0x404020],zmm0
│ 0x40114a <_Z3foov+42> cmp rax,0x200
│ 0x401150 <_Z3foov+48> jne 0x401128 <_Z3foov+8>
│ 0x401152 <_Z3foov+50> vzeroupper
│ 0x401155 <_Z3foov+53> ret
(gdb) layout src
asm-level and source-level debugging both work fine, stepping into intrinsic "functions" in avx512fintrin.h and so on when using stepi (aka si).
Without specifying the filename separately from connecting to the remote:
$ gdb
(gdb) target remote :46879
Remote debugging using :46879 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command.
0x00007f0f85830090 in ?? ()
(gdb)
(IDK if it matters that my .gdbinit includes layout reg, the full-screen terminal TUI mode. Nice when it works but somewhat buggy.)
Or as a super hacky workaround with PIE executables, I was also able to put a delay loop at the top of main, giving you a chance to attach and then control-C before SDE finishes executing your program.
Then I could set breakpoints and start single-stepping. (Presumably a sleep or read system call would work). Source-level debugging still seemed broken, but I was able to debug the asm with layout reg. I used set $rip = ... with a copy-pasted address to get out of the _mm_pause() loop after attaching and hitting control-C.
Here is my simple code while I want to use MPI_BARRIER in my program.I think my code doesn't have error,since I already add the param ierror.
program main
use mpi
implicit none
integer :: myid, numprocs, rc,ierr,i
call MPI_INIT(ierr)
call MPI_COMM_RANK( MPI_COMM_WORLD, myid, ierr )
call MPI_COMM_SIZE(MPI_COMM_WORLD,numprocs,ierr)
print*,"iter 1"
if(myid.eq.0) then
print*,"running",myid
else
print*,"running",myid
endif
print*,"waiting",myid
call MPI_BARRIER(MPI_COMM_WORLD,ierr)
print*,"end"
call MPI_FINALIZE(rc)
end program main
While I try to run it using
mpirun -np 2 ./test
There always has error like below
iter 1
running 0
waiting 0
iter 1
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x10392d579
#1 0x10392c945
#2 0x7fff90dc7b39
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault: 11 (signal 11)
I'm using MPICH3.2 and gfortran.And the fortran file is f90.I really don't know how to solve it.Thank you for helping me.
Maybe there is something wrong with my MPICH or the way I compile the program.
Since I use Mac OS,I just get MPICH use
brew install gcc
brew install mpich
While I use this to compile
mpif90 -fc=gfortran test.f90 -o test
When I compile my code using gfortran -g -fbacktrace -ffpe-trap=invalid,overflow,underflow File.f90 I get the following error:
Program received signal SIGFPE : Floating - Point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 0x7f3da0768ed7 in ???
#1 0x7f3da076810d in ???
#2 0x7f3d9fe9b7ef in ???
#3 0x7f3da0230a3e in ???
My question is: how can I interpret these numbers and ???'s under "backtrace for this error:". How can I use this error message to help me find the error? Are they somehow related to the specific lines of code that are problematic? If so, how?
As of now I realize I have an erroneous arithmetic operation error but I have no idea where and this backtrace error message doesn't help at all. If I compile using just gfortran File.f90, there are no error messages at all during compilation or during running.
It might depend on which target you're using. The GFortran backtrace functionality depends on libbacktrace, which might not work on all targets. On Ubuntu 16.04 x86_64 for the code
program bt
use iso_fortran_env
implicit none
real(real64) :: a, b = -1
a = sqrt(b)
print *, a
end program bt
when compiling with
gfortran -g -ffpe-trap=invalid bt.f90
I get
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 0x7F08C38E8E08
#1 0x7F08C38E7F90
#2 0x7F08C35384AF
#3 0x4007F9 in MAIN__ at bt.f90:5
zsh: floating point exception ./a.out
where on stack frame #3 you can see that the error occurs on line 5 in bt.f90.
Now, what are the stuff on stack frames #0-#2? Well, they are the backtracing functionality in libgfortran, the GFortran runtime library. libbacktrace for one reason or another cannot resolve symbols in a dynamic library. If I link it statically:
gfortran -g -static -ffpe-trap=invalid bt.f90
I get
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 0x40139E in _gfortrani_backtrace
#1 0x400D00 in _gfortrani_backtrace_handler
#2 0x439B2F in gsignal
#3 0x400C01 in MAIN__ at bt.f90:5
zsh: floating point exception ./a.out
I can't seem to get readable debugging output for programs compiled with GCC 4.7 MacPorts build.
I've tried with both GDB 6.3 and GDB 7.3 and each have their own problems.
Try with GDB 7.3 (MacPorts)
With GDB 7.3 I get the following output on startup:
$ ggdb ./test
GNU gdb (GDB) 7.3
Copyright (C) 2011 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-apple-darwin11.4.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test...Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test...done.
done.
Running and triggering an assertion results in an unreadable stack trace:
(gdb) r
Starting program: /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
main
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in ?? ()
(gdb) bt
#0 0x00007fff8ede282a in ?? ()
#1 0x00007fff9a273a9c in ?? ()
#2 0x00007fff6af00690 in ?? ()
#3 0x0000003000000030 in ?? ()
#4 0x00007fffffffffdf in ?? ()
#5 0x000000010b305840 in ?? ()
#6 0x00007fff6af006d0 in ?? ()
#7 0x00007fff9a2a65de in ?? ()
#8 0x0000000000000000 in ?? ()
Try with GDB 6.3 (built-in)
According to this answer I should use GDB 6.3. However that leads to a different set of problems. During startup I get a bunch of errors:
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011)
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 "x86_64-apple-darwin"...Reading symbols for shared libraries .
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list-2.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list-2.cc".
This is what I see if an assertion is triggered and I try to get a backtrace:
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in __kill ()
(gdb) bt
#0 0x00007fff8ede282a in __kill ()
#1 0x00007fff9a273a9c in abort ()
#2 0x00007fff9a2a65de in __assert_rtn ()
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Dwarf Error: Cannot find type of die [in module /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test]
According to this answer (which quotes the GCC 4.5 manual) I should use the -gdwarf-2 -gstrict-dwarf options.
I followed this advice. My build command looks like this:
g++ -o run-test -std=c++0x -Wall -Wextra -Werror -gdwarf-2 -gstrict-dwarf -g2 -O0 -I/opt/local/include main.cpp
However, it doesn't fix any of the aforementioned problems.
For the record: I'm on OS X Lion.
Does anyone know how to fix this?
According to the g++ man pages you should use -ggdb to generate debug symbols for gdb. BTW, just using -g always generated good symbols for gdb in my experience (on linux, windows (mingw) and mac).
The warnings from your MacPorts gdb 7.3 session are for load commands 0x24 (LC_VERSION_MIN_MACOSX) and 0x26 (LC_FUNCTION_STARTS). These are new load commands but are not essential for debugging - the warnings are harmless. The fact that your session lacks any symbolic information is maybe because of ASLR? It's been years since that was introduced into the system for user land debugging but that's what the debugger output can look like if it doesn't know that everything slid around in memory at runtime.
Have you tried using lldb? The version provided in Xcode 4.5 is really quite nice. It is the debugger that Apple is currently supporting and developing actively, and it should work with the DWARF output by more recent compilers correctly. The command syntax is a little different than gdb (although there are many command shortcuts provided that make it familiar to gdb users), there's a table of gdb/lldb command equivalences provided over at http://lldb.llvm.org/lldb-gdb.html. Give it a try, you might like it.
I have this output when trying to debug
Program received signal SIGSEGV, Segmentation fault 0x43989029 in
std::string::compare (this=0x88fd430, __str=#0xbfff9060) at
/home/devsw/tmp/objdir/i686-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:253
253 { return memcmp(__s1, __s2, __n); }
Current language: auto; currently c++
Using valgrind I getting this output
==12485== Process terminating with default action of signal 11 (SIGSEGV)
==12485== Bad permissions for mapped region at address 0x0
==12485== at 0x1: (within path_to_my_executable_file/executable_file)
You don't need to use Valgrind, in fact you want to use the GNU DeBugger (GDB).
If you run the application via gdb (gdb path_to_my_executable_file/executable_file) and you've compiled the application with debugging enabled (-g or -ggdb for GNU C/C++ compilers), you can start the application (via run command at the gdb prompt) and once you arrive at the SegFault, do a backtrace (bt) to see what part of your program called std::string::compare which died.
Example (C):
mctaylor#mpc:~/stackoverflow$ gcc -ggdb crash.c -o crash
mctaylor#mpc:~/stackoverflow$ gdb -q ./crash
(gdb) run
Starting program: /home/mctaylor/stackoverflow/crash
Program received signal SIGSEGV, Segmentation fault.
0x00007f78521bdeb1 in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x00007f78521bdeb1 in memcpy () from /lib/libc.so.6
#1 0x00000000004004ef in main (argc=1, argv=0x7fff3ef4d848) at crash.c:5
(gdb)
So the error I'm interested in is located on crash.c line 5.
Good luck.
Just run the app in the debugger. At one point it will die and you will have a stack trace with the information you want.