LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Segmentation fault (core dumped) (https://www.linuxquestions.org/questions/linux-newbie-8/segmentation-fault-core-dumped-4175528196/)

AlexBB 12-13-2014 05:25 PM

Segmentation fault (core dumped)
 
What does it mean in GFortran? I get it when I run a command ./a.out. Segmentation fault (core dumped) Thanks, - A.

Ser Olmy 12-13-2014 05:31 PM

Your program contains a serious bug/error, and was terminated by the operating system.

Typically, the program would have tried to access an invalid memory location. It's impossible to say what the problem might be without at least seeing the source code.

flshope 12-13-2014 07:41 PM

I have had segmentation faults several times from Fortran codes. The sorts of things I look for are:

undefined variables (I usually use 'IMPLICIT NONE' to eliminate this sort of thing)

variable type or length mismatch between variables in a calling argument list and the subprogram argument list

an array index way out of bounds (turn on the array bounds checker in the compiler)

rtmistler 12-15-2014 01:30 PM

Well you got a core file, which if you have a debugger, you can view the backtrace or see information about program variables and such at the time that the segmentation fault occurred. You can use GDB for this. You should have compiled your program with the -g flag, if you haven't, then re-compile with the -g flag, re-run and if/when you encounter the segmentation fault and get a core file you can then load that up using GDB.
Code:

gdb <executable-file> core
I haven't done this for FORTRAN but I'd imagine that you'd have a backtrace or some other capability to give you a report on what happened. If all else fails, create debug in various points of the code to document program progress so you can better zero in on where you hit the segfault. Or just run from within the debugger and when it hits the fault, you should be able to determine where in your program you were before hitting the fault.

flshope 12-16-2014 07:23 AM

locate the source of the segmentation fault with a binary search
 
Another way to try to locate the source of the segmentation fault is with a sort of binary search in the source code by inserting output statements (e.g., WRITE(*,*)'message'). The idea is to bracket the fault location in the source code by what you see on the screen after execution. One problem with this approach is that once the segmentation fault has occurred, execution may stop without having "flushed" all of the print buffers, which is to say, that the output of some successfully executed WRITE statements may not reach the screen. To flush the buffers, use a STOP statement after the most recently inserted WRITE statement (removing the STOP when you insert the next WRITE and STOP). This type of binary search is a crude alternative if the debugger doesn't tell you what you want to know, but it might reduce the amount of code you will have to scan visually to find your error.


All times are GMT -5. The time now is 02:26 PM.