Break Execution

Break Execution

I used to be able to use "Break Execution" command to stop the execution of the program. But, now, whenever I do that, a disassembly window pops up with no clear reference to the fortran source code. I even looked up the call stack to trace back the fortran files. But, each time, the call stack has only three or four references to other disassembly locations that does not tell me anything. Does anybody know how to fix this problem.

Ali Asi
asi@enginia.com

P.S. I am not sure, but it seems that this problem surfaced up since I upgraded my machine to Windows 2000.

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Is that lack of response to this posting is because nobody else has ever encountered this problem or is it because nobody knows the answer?! Anybody from Fortran development team here, ....?

Ali Asi
asi@enginia.com

Compaq was closed last week. I answered some things I knew, but left others alone.

I've never used this feature. My guess is that it has to do with the way Windows 2000 executes code. When you get the break, try doing a couple of step-out commands and you will probably find yourself back in your code.

Steve

Steve - Intel Developer Support

Thanx Steve for the reply. I tried your suggestion, but it did not quite work. The problem is that when I step out the first time, the program goes on to the execution of the program. Obviously, my goal of hitting the "break execution" was seeing in which routine I was in the first place. So, it does not make much sense to hit "break execution" and then without being able to see or inspect anything, let the program proceed with what it was doing by hitting "Step out".

Here is what I get in "Context" field of my call stack when I hit the "break execution" first time:

USER32!
HHCTRL!
KERNEL32!

Ali Asi
asi@enginia.com

Is you program multi-threaded? I have a Fortran application that is and I experience the same "problem" as you.

The solution is to go to Debug->Threads, select the thread of interest, Set Focus, and "voila", you get the call stack and line of Fortran you're stopped at. If your program has called a Windows API such as from SLEEPQQ, then the end point of the call stack will indeed be in some Windows DLL, but you should be able to step back in the call stack to the last Fortran code.

I'm also running Windows 2000.

Guy

Thanx Guy (alias:ghallibu)

Your replies to my postings were very insightful. I did as you suggested and in fact it did work. Here, I would like to sugget to Fortran development team to take a look at this problem and somehow fix it. To me, it makes much more sense for the development environment to have picked up the task that would have sent me to the Fortran source code. But, quite surprisingly, it always picks up the task that is hooked up to that disassembly window. I believe this is a flaw that can be easily addressed by Compaq/Microsoft team.

Ali Asi

Unfortunately, this aspect of the debugger is all Microsoft code that we cannot modify or control. It will be interesting to see what the debugger in VS.NET does here.

Steve

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today