- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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].
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Matt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The thread '
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not that I am aware of. If you can provide us a ZIP of a test case project, that would be helpful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try again with Update 3, which should be out within a week. I think issues with parentheses have been addressed there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Excellent,
Thanks Steve
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page