Inspector crashes when starting analysis with VS2012 debugger

[Mikhail_S_]

I am working with Inspector XE2015 integrated with Visual Studio 2012.

Inspector has helped me to find uninitialized variable. I want to use debugger in the moment when this error occurs. However when I start Inspector in one of modes "Enable debugger when problem detected" or "Select analysis start location with debugger" all crashes: first the debugged program, then the inspector, and at last the Visual Studio.

What conditions did not I follow to have a success with this matter?

[Mikhail_S_]

I think it is the address of sqrt function.

[Mikhail_S_]

In the above post you can find the value of memory cell esp register points to before call to sqrt.
 

[Mikhail_S_]

Can you run the same scenario by yourself and reproduce the error?

[Bernard]

Maybe somehow Inspector or the other code module modifies the content either of xmm0 register or esp stack pointer. Did you try to perform step in with windbg?

[Bernard]

Yes of course.

What is the source code and compiler options?

[Bernard]

Ok I see source code in attached screenshot. So I only need compiler options(switches).

[Mikhail_S_]

I have uploaded here the archive of the whole VS solution.

[Bernard]

Tomorrow I will run the test case and later I will post the results.

[Bernard]

I compiled your test case with Intel Composer 2013 (I still did not install Composer 2015) and run the sample program. Result was correct in debug version. I also ran Inspector memory detection analysis with debugger break in enabled and in my case VS 2013 freezes and Inspector does not complete its run. I checked with Process Explorer and VS 2013 is spinning in vsdebugeng.imp.dll consuming ~24% of CPU.

I need to troubleshoot it further.

[Bernard]

Were you able to solve your issue?

[Mikhail_S_]

My initial issue was unstable work of algorithm. I thought Inspector could help me to find if some variable is uninitialized in the code. During my experiments with Inspector I faced with this trouble that assemble instructions "movsd" work incorrect when the run is controlled by both Inspector and VS debugger. I cannot solve this issue, I think it is you (Intel side) who should help with this issue.

What concerning my initial problem (unstable work of algorithm), I solved it using other means (manual debugging, analyzing source code, print-outs, etc.).

However, I think it would be very useful to have this bug solved, in order to use this great feature in the future. I am ready to assist you further if you are willing to lead this deal to the end.

By the way, my hardware is Intel Core i5-2400 CPU @ 3.10GHz, 8 Gb RAM, Windows 7 64-bit Prof SP1.

[Bernard]

>>>I think it is you (Intel side) who should help with this issue.>>>

I am not employed by Intel. I am only forum member just like you.  Yes I am interested in your help and assistance needed to solve that issue. In my case my plan is to run VS and Inspector under windbg in order to understand why there is hung inside VS debugger engine.

In your case I would like to suggest running everything under windbg and break on line of code which is disassembled into movsd instruction. I suspect that somehow that code is modified when Inspector runs.

[Mikhail_S_]

Sorry, for some unknown reason I decided you are from Intel.

I would like this problem be analyzed by Intel professionals, because I am sure for 95% that it is a bug in their product. And I would not like wasting my time for playing with windbg and assembly instructions.

[Bernard]

Ok, so lets wait for the response from Intel engineers.

[Peter_W_Intel]

Thanks for test case - sample.7z

I opened this in VS2012, built it then run new analysis, and specify "Enable debugger when problem detected". However there was no error occurred so inspector didn't passed controller to debugger in VS.

Also, I verify this in command line -

>inspxe-cl -collect mi3 -- sample.exe

3.24037

0 new problem(s) found

I'm using Inspector XE 2015 Update 2.

[Mikhail_S_]

Please make sure you use the Inspector settings as shown in the snapshot settings.png above. The key point is "Detect uninitialized memory reads" is turned on. On my box, sometimes (very rarely) the program in this conditions also prints "3.24037", but almost always the result is "0". Now I have checked again, the bug occurs in both modes "Enable debugger when problem detected" and "Select analysis start location with debugger".

[Mikhail_S_]

I am using Inspector XE 2015 Update 1 (build 379161), MS Visual both 2012 and 2013 behave equal.

[Peter_W_Intel]

Thank you to clarify, I have a look at your screen shots, I'm using Inspector XE 2015 too.

1. First at all, ensure if there is memory access error. I ran your program without Inspector - no problem.

2. Check if there is memory access error when using inspector,

>inspxe-cl -collect mi3 -knob detect-uninit-read=true -- sample.exe

3.24037

0 new problem(s) found

3. Also I had no problem to run Inspector with VS2012 integration, with option "Enable debugger when problem detected" enabled. I suspected, there was other exception occurred in VS IDE then step into debugger. (Maybe, you can try same scenario in other machine)

Sorry that I cannot reproduce this problem, is there same issue from others?

4. I would like to suggest you, if met the crash again, please run -

inspxe-feedback -create-bug-report <report archive>

Then send logs to me, this will be helpful to diagnose root-cause. Thank you.

[Mikhail_S_]

I do not need to analyze the cause of the crash. I already know it. The cause is that some static object in some DLL is initialized with error, and the C++ exception is thrown. During Windows loading DLL there is no try/catch block set on the stack, and therefore thrown exception is unhandled and leads to the crash of my program. And the bug consists in that under Inspector+VS debugger the call to the function "ceil" returns zero, what leads to thrown exception by the logic of the object.

I have prepared a special isolated program sample.cpp that you are examining that contains no memory errors but allows reproducing the bug with incorrect calling a function. In my case this program prints "0" instead of "3.24037" when running under Inspector+VS debugger.

Please when reproducing make sure you have the following parameters:

- Win32 Debug configuration

- In Project settings/Code generation/Enable Enhanced Instruction Set is set to "NotSet" or "/arch:SSE2".

- Inspector analysis settings set "Detect uninitialized memory reads" to on, choose "Select analysis start location with debugger", Stack frame depth to "32".

My CPU is Intel Core i5-2400 CPU @ 3.10GHz.

[Mikhail_S_]

Dear Peter, I have sent you the report archive in a private message.

[Peter_W_Intel]

Finally I can reproduce this with stack-depth=32 and other options you used to build, output was zero but no VS crashed.

Thanks for your logs, I have escalated this to developer for investigating.