TWO Line program hangs up the debugger

[WSinc]

         read(*,*)

         end

When it gets to the READ statement, I want to close the window, which generates a breakpoint.

But when I wanna quit and do something else, I get the little blue circle, and then it makes some remark about "debugger is unstable, save all files and exit"

so apparently, the debugger is going off into la-la-land, and hanging everything else up, 

I have to close the VISUAL 2013 app entirely and start over, to do anything else.

Dont they test this stuff ? Too bad we're stuck with Microsoft products.

[WSinc]

BTW, restart, or stop debugging both cause the same problem.

But if the program exits normally, I can start debugging again.

So, apparently setting the breakpoint is what triggers this difficulty.

Unfortunately, it sets a breakpoint when we close the output window = =

so we are stuck.

[FortranFan]

billinscl wrote:

.. when it gets to the READ statement, I want to close the window, which generates a breakpoint.  But when I wanna quit and do something else, I get the little blue circle, and then it makes some remark about "debugger is unstable, save all files and exit" so apparently, the debugger is going off into la-la-land, and hanging everything else up, ..

Bill,

Using the "Stop Debugging" (Shift+F5) option with Visual Studio 2013 on your 2 line code - which is all I'm wiling to try - the problem is not reproducible.

You can wail all you want about Microsoft and Intel Fortran and its integration with VS but until you are able to furnish the necessary problem description and associated details, which you singularly fail to do in this thread and in your other threads, your problems are highly likely to be viewed as PEBKAC.  You, me, and the users all know there is a lot that can be better with VS and Intel Fortran but any drawback in these tools is not the root cause of your affliction, the "entangling alliances" in the ever more complex computing environment might be making your condition worse but I doubt they are at the source.

Each and every statement you make all point back to the need for you to become far better informed.

[WSinc]

Well, it would be nice to know what about my environment that might cause this problem.

after all, it is the newest CPU (64-bit), and newest Fortran (17.0),

so there is no reason to expect problems like this.

anyway, I was hoping to get an intelligent suggestion, instead of these stupid remarks.

If someone can log in remotely, I can easily demonstrate what happens.

actually, just being able to exit a program without generating a breakpoint might be a good work-around.

We cannot now, as far as I know close a window without causing a breakpoint, which seems kinda redundant.

[Kevin_D_Intel]

Everyone,

With all due respect,

@billsincl - I know it is frustrating when the Development tools do not work. We all recognize you are experiencing a number of issues and we are trying to reach out to help. I will be in touch to offer some remote access/help to see if we can work through the issues you are facing. Please remain respectful and focus exchanges on what will help resolve issues or answer questions.

On behalf of Intel, we thank everyone for their active participation, willingness to share knowledge, and deep desire to help others. Our Fortran forums are among the most active, friendly, and respectful of our forums and we certainly want them to continue with those traditions. There is a great community of Fortran users in the forums with a deep knowledge, passion, and desire to share and help, and I know none of us wants to distract from that. Let us all please do what we can to remain respectful in our exchanges.

Thank you.

Sincerely,
Kevin

(Sorry, for replicating – just trying reach everyone in the various threads)

[mecej4]

About the problem described in #4: you may be creating a deadlock by closing the output window.

Your program did not open the window; the debugger did, and the debugger expects the window to be open until the debugger itself closes the window. Your closing the window, if not provided for, may disrupt the whole machinery. The debugger could be waiting for a signal from the OS that writing to the window has finished, and the window manager may be waiting for a keyboard event from that window. If every piece of the complex pieces of the system does not behave as intended, the whole system may crash. As far as Windows is concerned, your closing the window is unexpected; if every process in the chain of command does not check that the other processes are behaving properly, the non-cooperation can cause a hang-up. If every process did check, on the other hand, the software would be bloated even more than it already is, and the user would complain about its being slow.

Unless the user has a solid understanding of the internal machinery of Windows programs, it is best to refrain from interventions such as closing windows that were not directly created by the user.

[WSinc]

I was talking about the OUTPUT window, that is brought up anytime execution starts.

You get that even when you say "start without debugging."

Of course, when you say READ, you have to type something into that same window.

Now closing that window generates a breakpoint. so the trick is to stop execution without the crash.

Actually, sometimes I can say "continue" and that seems to exit without forcing the big hang-up.

[andrew_4619]

So what happens if you select the "Stop Debugging" option from the "Debug" menu does that hang?

[WSinc]

That hangs it up - also "restart" .

"continue" does not, though.

so that could be a work-around.

[andrew_4619]

I can sort of repeat some of your problem but after a short blue circle of death period the system recovers OK on my machine.

Hitting the to close the application window is not a good thing to do in your 2 line program. There are no break points set so the debugger is waiting  for some instruction to attach to your program. You then crash out your program with the on the window. The debugger default behaviour is to look for 'exceptions' i.e. crashes in your code and it sees one. It then wants to attach to the first code it can find after that crash but your program has already gone so the debugger can get confused, what happens next could be quite unpredictable.

If you want to stop debugging don't close the application window use  the stop debugging menu option. That will stop the debugger and close your program. 

You seem to be saying stop debugging does not work but is that after you have closed the window? If you have not closed the window and you are just waiting at the read(*,*) then there is something wrong with your system I think as it is not the behaviour I see.

I

[jimdempseyatthecove]

>>I was talking about the OUTPUT window, that is brought up anytime execution starts.

You have a basic misunderstanding, that is likely causing your confusion. When you debug a console application, what you are (mis-)referring to as an output window is the Process window of the executable being debugged. When you click on Debug in VS IDE it launches your program (being debugged) as a child process of the VS IDE complete with its own console window (and the debugger immediately attaches to the process). The console window that you see, with exception to the VS debugger attaching to, is no different than the console window following

(in MS VS with solution & project open)
Build
Move mouse to Windows start button
Click on Start | Run | cmd
(new CMD window now opens)
cd \YourProjectFolder\YourConfig\YourReleaseOrDebugFolder
YourProbram.exe your args here

At this point you have two "windows" on your desktop: the MS VS IDE window, and the cmd window running your application

In both cases, closing the cmd (console) window kills the application, but does nothing to the idling MS VS IDE.

In the case of being launched via MS VS Debugger, killing the process and its cmd window and (is supposed to) return to the MS IDE Edit session (not to the Debugger). The MS VS IDE is left running.

In the case of being launched via a command line inside a cmd window, it terminates not only the application, but also the cmd session/window. The MS VS IDE is left running.

As Andrew says: If you want to stop debugging don't close the application window use the stop debugging menu option

This option is a button on the MS VS Debug toolbar, with an icon that usually looks like an outlined red square button. Another useful button is the Break button, which typically looks like a Media Player Pause button (two vertical bars ||).

Jim Dempsey