If you're still interested, you can reset your preferences for the debugger by opening your home folder and deleting a file named gdbtk.ini.  It should cause SIGSEGV errors to be displayed once again.  If your Windows user name is the same as your forum name, the file should be located at (on Windows 7 or higher):

C:\Users\wwang328\gdbtk.ini

There shouldn't be any other side effects caused by deleting the file.

Other users please note that this fix only applies to Simply Fortran 1.45 and earlier.

    I figured out why there are SIGSEGV error message. Basically I'm calling a subroutine
   

 subroutine trans(v,a,b) 
             real(8), intent(out):: v(5) 
              ....... 
 end subroutine trans  

    In my main program, I did something like this
   

 real(8) :: m(10,5) 
             integer :: i
            do i=1,10 
                call trans(m(i,:), a,b)
            end do 

    This seems to be conflict with Fortran's rule of storing arrays by column and causes a runtime error, after I have the -fcheck=all in compiler flag.  If m(10,5) is changed into m(5,10), the problem disappears and the debugger is working as it should be.

Wenya

If you do not supress SIGSEGV, you should be able to determine where the crash in your code is occurring.  The question marks in the stack window are only indicative of confusion on the part of the debugger concerning where your code is crashing.  The "illegal input passed into the Fortran runtime library" terminology was trying to imply that perhaps you're asking the Fortran runtime library to print the 200th element of a 100 element array or something similar. 

When you added the "-fcheck=all" flag and ran your program outside the debugger, you didn't receive any diagnostic messages?

    Thanks for your quick reply. I tried the flag -fcheck=all. It seems not killing the problem.

    However, I had this problem from some history, which might provide some useful information. The situation I was facing previously was similar to a previous post http://forums.approximatrix.com/search. … 0&p=3. I could run the program but when it came to debugger, the following message window showed up

   Signal received SIGSEGV - Segmentation fault 

    Somehow, I clicked the box

 Don not show me this message again 

.

    After that, the debugger started to have the symptom of stopping at a random address. I tried the Stack window and it seems uninformative with two lines of questions marks:

 ?? 
               ?? 

     So, basically my two questions are: (1) is this problem related to my clicking of not showing SIGSEGV error message? (2) Are the question marks of Stack window pointing to "illegal inputs" as you mentioned earlier?

      Thanks very much!

-fcheck=all

in the "Fortran" field under Flags to enable runtime diagnostics.  It can be helpful in determining if array bounds have been exceeded.

One thing you need to remember is that the compiler will not produce an executable if either a) it can't find a specified include file (nlopt.f in this case) or b) it can't find the library for linking.  Regardless of whether you've installed the library per their directions, you wouldn't end up with an executable if the compiler couldn't find either the library or the include file.  Additionally, the fact that the example works fine suggests that the problem is not related to the library itself.  I wouldn't worry about the "correct" directories since the compiler seems to be finding the files it needs properly.  Their location would not affect runtime results.

For debugging, when the debugger "stops" at the seemingly random address, open the "Stack" view to see what calls led to that address.  It is quite likely that some illegal input passed into the Fortran runtime library is causing the program to halt in the debugger.  The debugger isn't perfect, though, so I urge you to try the compiler flag I suggested earlier.

    Obviously, it's speaking to users who are in Unix system (correct me if I'm wrong). After digesting a little bit with the make file I previously got, I put the nlopt.f and nlopt.h files into

 C:\Program Files (x86)\Simply Fortran\mingw-w64\x86_64-w64-mingw32\include 

     and changed compiler locations to those under (resource compiler location wasn't changed as I didn't find windres.exe in the following folder)
   

 C:\Program Files (x86)\Simply Fortran\mingw-w64\x86_64-w64-mingw32\bin\ 

   
     while the default is

 C:\Program Files (x86)\Simply Fortran\mingw-w64\bin\ 

     Now the punch line question is: if make file "errors" are not true ones, am I installing the library in a correct way from their instructions?

     IDIR=
# -I error: Directory C:\Program Files (x86)\Simply Fortran\mingw-w64\include\ does not exist
# -I error: Directory \64\include does not exist

LDIR=-LC:/PROGRA~2/SIMPLY~1/MINGW-~1/lib/
# -L error: Directory \64\lib does not exist

Those "errors" are informational only. There are certain directories that Simply Fortran assumes it should check for additional Fortran 90+ modules or C include files and additional libraries.  If the directories aren't present, a message is left behind in the Makefile.  If these missing directories were actually supposed to include a file the compiler needed for your project, compilation wouldn't complete.   The current version of Simply Fortran (2.24) has renamed these as "warnings" to try to alleviate questions about the messages.   It's meant to be useful if, for example, a user has specified a library directory manually that doesn't exist.

If you're having issues computationally, try enabling some of the Fortran diagnostics in Project Options (under the Fortran tab, select "Enable Runtime Diagnostics") and disabling all optimizations.

    I was using NLopt library (see a previous post http://forums.approximatrix.com/viewtop … 165#p2165) for a constrained optimization problem.

    Seemingly, the code is running. However, it's goofy that constraints of the problem are violated at maxims. Later, I notice that in the make file, there are errors like this: 

     IDIR=
# -I error: Directory C:\Program Files (x86)\Simply Fortran\mingw-w64\include\ does not exist
# -I error: Directory \64\include does not exist

LDIR=-LC:/PROGRA~2/SIMPLY~1/MINGW-~1/lib/
# -L error: Directory \64\lib does not exist

     What puzzles me is that if this is the cause, shouldn't be any functions and subroutines in the library not working at all? In a simplest testing project, the library indeed can get the true maxim, even with the existence of same error in make file.

      Am I stuck in an irrelevant error? Thanks a lot!