One thing I would suggest is changing your target name to something without parentheses.  A good number of GNU tools do not play well with parentheses in path names, and Insight is probably not happy about the executable's name.  I would alternatively suggest using the name "InStruct117-32bit.exe" and trying Insight again.

The one thing I did change is that under project options, I have only the executable name in the "Target Name" dialog. Jeff had me remove the full path name to the executable. Since then, things are working.

The other thing that is different is that I did download version 1.38 and install it. It could be that I registered the product last night, LOL.

Thanks again for all the help.

Rod

I'll start looking into the debugger issues.  I can't say what's wrong right off the top of my head.  Would you mind emailing me your makefile just so I can have a look?

after you open the debugger and launch the executable, if you click the icon for going to the next debug break point, then the debugger does start doing what is intended and you can step into and out of and through the next code lines as intended,

...doesn't work for me.

I do this:
- open the debugger using the debug icon,
- check correct breakpoints still set,
- launch, using the 'Run (R)' icon.

I do not get the chance after this to click the next debug break point icon, 'Next (R)', in the way that Rod has been able to do, because the display panel blanks half a second after I press the 'Run (R)' icon, with the 'Select function name' error message at the top:

'Select function name to disassemble'.

All debugger icons are active but the the 'Next (R)' icon just flashes the icons panel fractionally and returns to the same blank panel with the same error message.  I've tried holding my finger on the 'N' key to hammer it with repeats of the same command.  Same result.

I've also tried running the Insight debugger executable manually, not running it from within SF.
I've tried it with both the 64-bit and 32-bit versions (my executable is built on a 64-bit laptop, as 32-bit code).
Same result both times.

One final clue I've noticed:
After running the debugger, before launching the application, the selector at the far RHS of the display is set to 'SOURCE'.
When the error occurs, it has changed to 'ASSEMBLY', and will not allow me to re-select 'SOURCE'.
---
John

I made the changes you suggested to the launch configuration and that workaround does the trick. Is the debugger supposed to use the same command line options put in the launch section?

I am able to debug now. One trick I discovered is after you open the debugger and launch the executable, if you click the icon for going to the next debug break point, then the debugger does start doing what is intended and you can step into and out of and through the next code lines as intended. Perhaps John can try that too to get it working.

Debugging an OpenMP code with a single thread is probably the way to go. However, the debugger will not step into an OpenMP directive set of code. I am not sure if it should but it would be nice.

Now I have to figure what my crazy code is doing...

Rod

I just posted a bug about your Launch button issues.  I'll look into a new build of the debugger.  Let us know how restricting debugging to a single thread works out too.

-----------
...the debugger is my immediate problem. When I open it up, all seems normal. I open the executable to be debugged and then it opens the code in the window for a brief second (as what was normal before) but then goes blank with the following message:

"Select function name to disassemble"
I can reopen the code again, but can't step into anything or run to break points.
-----------

I have been having exactly the same problem for some weeks, with one of my projects.
I can set breakpoints OK but when I try to run, the debugger emits exactly the same error message as above and then operates exactly as Grogley has described..
I've switched back to the old way of debugging, by inserting print statements.  So slow.

I am compiling on a 64bit laptop for 32bit code.
No optimisation is set.
----
John

As per email to the support group, I sent PRJ and MAKEFILE files to you. I also downloaded the latest version, 1.38 and installed it.

I am able to debug now it seems but still behaves oddly. It will also crash if I restart it several times, which is not a big deal.

Suggestions to limit my debug to single threaded code make a lot of sense and I will try do that going forward.

Rod

I downloaded the SF image this month, just a few weeks ago. I think I am using 1.37? My first post to the forum was on 1/14 and 1.38 was release on 1/14, so probably I am using 1.37. Does that sound right? I will send you some of the asked for information when I get home tonight.

Rod

Conceptually, I would guess that some lines could be "optimized out" when any sort of optimization is enabled.  When I'm debugging, I do indeed try to avoid enabling any optimization. 

The launch button is automatically and internally configured to launch the target program (as defined in Project Options).  Command line arguments would be to add any arguments you wish to pass to your program, and it should not contain the executable name itself.  The working directory can usually be left blank, which indicates the program should run in the directory in which it was compiled.  If the launch button isn't working, something else is quite wrong.  If that's the case, you can email me your project file (ending in ".prj") and Makefile to troubleshoot the issue.

What version of Simply Fortran are you working with?  I just want to make sure that you're running the most up-to-date version.  Also, what is the name of your target program and in what directory are you working?  Some tools can have issues with paths containing spaces or parentheses.

Thanks for the quick response. Here is some more information.

As far as optimization, I do disable optimization and when I do, things behave better (not perfect as there may be coding issues that I need to debug). It is when I set the -O2 option in the build step that things go really weird and I notice that lines of code get optimized out.

Debugging is enabled during the compile and build step. I am compiling for 32 bit executable for now but my workstation platform is 64 bit. When building, I always do the clean step.

I didn't think to look at the Makefile for issues but I probably wouldn't understand what those issue would be anyway. I will check that out tonight when I get home from work. If needed, I will send the makefile to you then.

Another issue I am having is the launch button. How do I configure that to launch the program. I have the default directory set but it can't seem to find the executable to use. Do I enter the executable name into the above command line options text box(I've done that but it makes no difference)? What goes in there exactly? LOL!

Thanks again for your help.

Rod

Have you tried disabling all optimization first?  The compiler shouldn't perform any optimization unless directed to do so.  The symptoms you're describing seem to suggest that debugging was disabled at compile time.  If you've been playing with compiler options, it is usually advisable to clean the project after making any sort of change. 

What architecture are you compiling for, 32- or 64-bit?  If you are on 64-bit Windows, I might also suggest trying both 32- and 64-bit builds to see if there is any difference.

If you continue to have issues, you can email your Makefile to me at support@approximatrix.com for me to examine to see if I can sort out if a compiler option is causing the issue with the debugger. 

Sorry for the issue.