IVF debugger crashes VS2k10 when stepping into some functions

[mford78]

I know the title is less than useless, but I am seeing some odd behavior and wanted to know if anyone else has ever seen it as well. When I am debugging our big code base and stepping through, I have found a handful of subroutines that, if I attempt to step into them (using F11), will simply crash VS outright. Now, I can set a breakpoint on the subroutine's first line and "not" step into them (via F10) and then I get taken to my set breakpoint and I can continue along without issue...

Has anyone else ever seen this? My first attempt at figuring out what is different about these functions then others and creating a test program to attach here proved unsucessful, but I'll keep trying. I am just looking to see if I am out in left field alone or in good company. Thanks.

Using VS2010 Pro, and Intel Composer XE 12.0.4.196 [IA-32].

[Wendy_Doerner__Intel]

Are you trying to debug optimized code. That can confuse the debugger since our compiler may optmize away some routines (although it should never crash). You can try the debug version of the project to see if the same crashes happen. I have not seen the debugger crash though in the way you describe to address your question. Note there are more recent releases of 12.1 that you may want to try also.

------

Wendy

Attaching or including files in a post

[mford78]

Wendy, this should be fully unoptimized (debug) code. I will double check in the morning and see if an upgrade to update 7 changes the behavior. Hopefully, I'll be able to create a test program that exhibits this odd behavior.

- Matt

[mford78]

Upgrading to update 7 (IVF12.1) did not change the behavior. I attempted to take one of the "failing" functions and put it into its own driver program. However, when I did this it worked as expected. I will keep searching for what makes these functions different from others in our code base and hopefully exploit that into a reproducable example.

[Rob_Mueller-Albrecht]

Hi Matt,

from the information in this thread I can only guess, but it sounds to me as though inconsistent symbol info at the entry point of the subroutines that you are trying to step into may be to blame.

Do you have a callstack of the VS crash?

Please let us know when you have been able to put a testcase together. It would be very much appreciated.

Without more information on the crash itself, I can only assume that the symbol info for the optimized code is bad at these subroutine calls. The question is whether this can be captured and handled appropriately in the debugger or whether it should be dealt with in the compiler, or whether it is some side effectofcomplex build settings.

Thank you, Rob

[mford78]

If I can, I'd be happy to provide that information. I don't know of a method to get the call stack of VS at the time it crashed, can you point me to a website or tool I could use to obtain that information?

Also, how can I check if the symbol information is good or not? I had a similar thought, and went through a complete, build, rebuild, clean, build cycle and am still seeing the behavior. Speaking with my coworker today (we have nearly identical setups, difference is he run Win7 64 bit, I run Server 2k3 32bit) he is seeing the same behavior, which would lead one to the conclusion that it is something in our build. Is there a better trick to force a complete clean rebuild of the debug information? Thanks for the contiued help.

[Rob_Mueller-Albrecht]

Getting a call stack of a Visual Studio session is actually a bit tricky and requires two instances of Visual Studio. Details are described on MSDN:

http://blogs.msdn.com/b/vsdata/archive/2009/06/08/how-to-get-call-stack-of-visual-studio.aspx

The steps you take to do a clean rebuild seem to be absolutely correct. If you want to be 100% save you could manually delete the object files of your debug output directory, but that should not be necessary.

I guess the first step may be to have your build settings. You can get a complete detailed Intel compiler build log with the /# option. This should also give us the complete command line. Yu could provide us that input in a private response.

A real nice testcase would still be best, but I know howdifficult they can be to create.

Thanks, Rob

[mford78]

Rob, thanks for the tips! I tried getting a call stack using the method outlined in that MSDN blog post, but it did not work as it doesn't seem that VS is throwing an exception which can be caught, it is just outright dying. Following those steps, I was able to get this information from my "debug" instance of Visual Studio (about the crashing instance of Visual Studio):

The thread '' (0xf28) has exited with code 0 (0x0).
The program '[3184] devenv.exe: Managed (v4.0.30319)' has exited with code 128 (0x80).

My Googleing doesn't return too much useful information about how error cose 0x80 may be playing a role here.

In the debugging instance of Visual Studio, there is no option to get a call stack, the runtime instance of Visual Studio is simply gone.


The only other information I have gotten so far just muddies the waters further. Our solution where this is occuring contains a number of seperate, loosely linked projects. I tried repeating the test (stepping into a function that I believed would crash VS) on another project and there was no crash, I stepped right into the function I wanted to. I am currently trying to see what difference there is between these two projects as they should be very similar.

[Rob_Mueller-Albrecht]

Thanks for keeping me posted.

Based on the latest status I am afraid I cannot make any goodalternativesuggestions at this point either. Please let me know when you find out what the difference between the two projects or between the installed tool sets (ours as well as Visual Studio) may be.

Thanks, Rob

[Corwin_O_]

I realize this is an older thread, but I am getting the same behavior with certain subroutines.  I am also using VS2010 and Intel Visual Fortran.  Did anyone figure out what causes this?

Thanks,

Corwin

[Steven_L_Intel1]

Not that I am aware of.  If you can provide us a ZIP of a test case project, that would be helpful.

[andrew_4619]

I have had the same behaviour quite a number of times over the last coupe of years in non-optimised code, if you step in VS 2010 crashes but if yiou set a break point it doesn't. I have never found any explaination but just worked around the problem. It work be hard top provide a  small example that illustrates the point.

[dannycat]

I have experienced the same behaviour on a recent version of the compiler but after installing the latest update XE 13.1.0.149 the problem has not occured since (touch wood)!

One problem that I do have is that the text buffer getting mixed up when entering text in the source editor while a compilation is being done simultaneously. The problem seems to be worse when typing in parentheses. The text can come out in reverse order or partially mixed. I suspect that some intellisense feature is trying to find some match for functions when the "(" character is entered but because the processor is busy with the compilation it takes a long time to search and when search is over I've typed more characters that get lost or put in the wrong place. Has this been reported before and what can anyone suggest as a workround? I've seen this happen on both XP and Windows 7 OS (64-bit).

Thanks

[Steven_L_Intel1]

Try again with Update 3, which should be out within a week.  I think issues with parentheses have been addressed there.

[dannycat]

Excellent,

Thanks Steve