Why does VS 2013 keep hanging up ?

[WSinc]

When I first go into VS 2013 it compiles and does a build with a second or two.

The problem occurs when it hits a breakpoint, and I want to quit and restart.

I say "stop debugging," and I get the blue circle for about 15 seconds, and then an error message,

to the effect that the DEBUGGER MAY UNSTABLE then I cant reference the EXE or do any more builds,

or restart it.

To proceed , I have to quit VS 2013 entirely, and start over.

I dont see this hangup when the program exits normally, like with a STOP command.

So there is some process going on that interferes with any further work, until I quit the VS2013.

Incidentally, sometimes I get "CANNOT WRITE THE MANIFEST, about 25 percent of the time, but then I can still do the rebuild by trying again.

I can attach the two source files, but I dont see the relevance. It is not in my source code, its in VS 2013.

Dont we have something to say about the quality of stuff we get from Microsoft ?

[mecej4]

Why is the debugger apparently hanging up? Because your program is taking a long time to run.

Your program solves three simultaneous equations in your  SOLVE subroutine (which is incomplete because there is no back-substitution code, but that is not of concern yet) in less CPU time than can be measured accurately. However, your post-solution checking code contains DO loops nested, in effect, nine-deep, so the innermost loop may end up calling subroutine ROW4 on the order of 16⁹ times. Now, 16⁹ takes 36 bits, so your counters such as NROW, which have only 31 bits, could overflow several times. 

A more serious consequence is that this checking code will consume a lot of CPU power. What do you get, in return?

As it is, ROW4 is called only if certain values of CHEK() are .true. A slight change to CHEK could make your program slow down even more.

If you compiled the program with debugging turned on, it could take about a minute to run these loops, with all diagnostic PRINT statements disabled. Inside the debugger,  or with the PRINT statements active, the program could keep running for a very long time.

You need to choose a different method of checking.

[JohnNichols]

1. Manifest == this is a switch in the properties, sometime you just need to turn it off - quite simple and is covered in a Google search quite well.

2. Quality == actually you should try the older say Microsoft Fortran V3.3 in the late 1980s - this is so so much better at finding errors and developing code that can run in something approaching real time.

3. Loops == if one Lisps one learns to recurse - if you have nine deep loops can I suggest you recurse - try the Abelson and Sussman book.

Just a thought - of course being torn apart by mecej4 is a price one has to pay for this valuable forum. Of course he tears everyone apart so it is equal for all. 

Merry Christmas

John

[WSinc]

Well, it never gets to that part of that program.

I close the window BEFORE it goes there, so the breakpoint is generated by the Window Close.

But the debugger apparently is going on and doing some other stuff without my knowing about it.

and that interferes with the files I am working on.

So the issue is: why does the debugger keep on running when the program is stopped ?

Why didnt MECEJ4 Retire? I am gonna miss Steve.

[Andreas_Z_]

After the program hits a breakpoint, do you just close the command terminal window in Windows or do you click on the "stop" button in VS? The latter would be appropriate and should not lead to a crash of VS or a long delay.

[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)

[Steven_L_Intel1]

Same as https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/705492