I want to detect stack overflow or corruption in my code. Hence, i wrote a small program where stack overflow is simulated. I compiled it using the command:
gcc overflow.c -g -fstack-protector-all
However, upon executing the binary i got segmentation fault but no other information.
Can anybody please help me where did i go wrong?
If ulimit -c is set to a value much bigger than zero, a core dump named core is written; you can see the backtrace via running gdb program core and then typing backtrace at the prompt.
Related
I am currently trying to write a GCC backend for a new architecture, but when I try to compile it I get the following error message:
xgcc: internal compiler error: Segmentation fault signal terminated program cc1
The build is configured with the following command:
../gcc/configure --prefix=--prefix=$HOME/GCC-10.0.1 --disable-bootstrap --target=arch_name --enable-languages=c
How would I go about fixing this error so that I can build my backend?
As far as I am aware, I have implemented the target macro's, functions and insn patterns required to get GCC to build.
Sorry that the question is a bit vague, I am not sure what extra information I can provide. If more specific information is needed please let me know and I will edit the question.
Thanks in advance.
How would I go about fixing this error so that I can build my backend?
Debug cc1.
xgcc is located in $builddir/gcc. Hence run $builddir/xgcc -B$builddir -v -save-temps <options-that-crash-cc1>.
xgcc -v ... will print the sub-commands it is calling, record the options it supplies to the crashing cc1 call.
Run a debugger against that cc1 call, supply the right options and put a breakpoint at abort (will be fancy_abort) actually.
Build the compiler without optimization. It's enough to run make in $builddir/gcc for that. You can supply additional option if you like, e.g. make -j4 cc1 CXXFLAGS='<flags-to-pass>'.
$builddir/gcc provides .gdbinit to augment gdb with additional hooks to improve debugging experience.
I'm currently using a stack script, and am wondering if this could be sped up by explicitly compiling it to an executable, or alternatively caching the object code so that stack will not recompile every time. Maybe it is already doing the latter - certainly it is for dependencies, just not sure about the object code of the script itself. In which case, I guess I just need to write faster code!
You can use stack exec ghc to call the ghc installed by stack. Example usage:
stack exec ghc --resolver lts-15.0 -- -o test Test.hs
I took the advice that is given in the comments of this question Gfortran does not tell me what sort of FPE it is i.e. start up GDB , set a breakpoint to that line and inspect the values of the operation. At the outset my program is based on Fortran 77 code(I plan to migrate it to F90 after running this "test case" an idealistic CFD data test) and uses NetCDF shared libraries on Ubuntu 16.04 LTS. I use the gfortran 4.8.5 compiler(can upgrade to 5.x if required).
This is how the program is compiled
gfortran -Wall -O0 -c -g -fbacktrace -ffpe-trap=invalid,denormal,zero,overflow,underflow ${tool}.f ${ncdf_incs}
Now I started gdb in the directory where the program is located and then I typed
break inv_cart.f:1221
which is where the FPE is occurring(a divide by zero error). When I do this I get this message -
Make breakpoint based on future shared library load (y/n) ?
So I searched SO for this problem and I got this previously Q/A - How to set breakpoints with shared libraries and this is what I did
set breakpoint pending on
break inv_cart.f:1221
UPDATE
I had an oversight. After I run break I get this error message
No symbol table is loaded. Use the "file" command
Breakpoint 1 (inv_cart.f:1221) is pending.
END UPDATE
After I do this I get the same error I got when I ran inv_cart within gdb or as stand alone.
Program received signal SIGFPE - arithmetic exception
followed by a memory address and couple of question marks followed by ().
So I quit gdb and then it tells me that there is a a debugging session that is still active.
So my question still remains - How do I obtain the values where the FPE is occurring ?
This is a straightforward problem after the update has been noticed by me.
I looked up this question - gdb no symbol table is loaded and I went ahead and did this
file inv_cart
and finally the symbol table was loaded and to my joy I ran the program again via gdb and was able to print the value of the piece of code where the FPE was occurring.
I wrote a CUDA application that has some hardcoded parameters in it (via #defines). Everything seemed to work right, so I tried some other parameters. Now, the program doesn't work correctly anymore.
So, I want to debug it. I compile the application with -deviceemu -g -O0 options, because I read that I can then use gdb to debug it. In gdb, I set a breakpoint at the kernel start using break kernelstart.
However, gdb, jumps at the start of my CUDA kernel, but I can not step through it, because it doesn't let me inspect things within the kernel. I think it's best if I give the output of gdb:
Breakpoint 1, kernelstart (__cuda_0=0x100000, __cuda_1=0x101000, __cuda_2=0x102000, __cuda_3=0x102100) at cudatest.cu:287
(gdb) s
__device_stub__Z12kernelstartPjS_S_S_ (__par0=0x100000, __par1=0x101000, __par2=0x102000, __par3=0x102100) at /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c:7
7 /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c
(gdb) s
cudaLaunch<char> (entry=0x804a98d "U\211\345\203\354\030\213E\024\211D$\f\213E\020\211D$\b\213E\f\211D$\004\213E\b\211\004$\350\r\377\377\377\311\303U\211\345\203\354\070\307\004$\340 \005\b\350\345\341\377\377\243P!\005\b\307\004$x\234\004\b\350\b\001") at /usr/local/cuda/bin/../include/cuda_runtime.h:773
(gdb) s
(gdb) s
cudatest (__cuda_0=0x100000, __cuda_1=0x101000, __cuda_2=0x102000, __cuda_3=0x102100) at cudatest.cu:354
(gdb) s
After, this, it jumps back to my main procedure.
I know that my specifications are more than vague, but can anybody guess where the problem is? Is it possible to inspect kernels using gdb?
Use cuda-gdb
Compile: nvcc -g -G filename.cu
Invoke cuda-gdb on your a.out
You can set breakpoint inside your kernel function as usual.
Run the program, and it should stop inside your kernel function.
You can even get details of the current thread which is being executed using commands like cuda thread. Other commands like cuda block exist.
To switch between threads say cuda thread (x,y,z)
For more details refer to the latest version of cuda-gdb's documentation. If you are using the latest version of cuda toolkit (ie, 3.2 as of today), make sure you are looking at the latest version of the documentation (as the options have changed a lot).
And also make sure you are running cuda-gdb from a console (outside X11), since you are stopping your GPU for debugging.
Hope this helps.
Compiling with :
nvcc -g -G --keep
fixed this problem for me. This ensures all the intermediate files generated during compilation are not erased so that the debugger can find them.
I have a compiled .exe file (compiled with gfortran and -g option) that crashes. I can attach the WinDBG program to it using the WinDBG -I command.
Funny enough it generates a stack overflow:
(38f0.2830): Stack overflow - code c00000fd (!!! second chance !!!)
However, the output says that there is no debugging information in my program. It tries to search for either .dbg or .pdb files but they are not there. I would assume debugging information is included in the executable (coming from a unix-background).
Debug formats are compiler specific, so you need to use a debugger that understands the format produced by your compiler. As by gfortran I assume you mean GNU fortran, this would be the GNU gdb debugger.
I circumvented the problem by starting the program via gdb. In this way, gdb will give an error and you can issue the backtrace command.
It's not perfect, so I'm open for better solutions, but this works for now.