VS2010 - Breakpoint generates "Illegal Instruction" exception

[Bernhard_Zellner]

I have a small test project for boost serialize.

When running the release version of the test project the program runs till the end.

When setting a breakpoint in the release version in BoostSerialize.cpp line 332 then i get

"Unhandled exception at 0x00364645 in BoostSerialize.exe: 0xC000001D: Illegal Instruction."

I am using VS2010, Intel Compiler 14.0 SP1 and boost 1.54, static linked. boost is compiled with the following settings:
using intel : 14.0 : $(intel-compiler-14)/bin/ia32/icl.exe : <compatibility>vc10 <cxxflags>"/Qstd=c++11  /Qipo /Qdiag-disable:2586 /D_CRT_SECURE_NO_WARNINGS" ;

The test project is attached as zip file.

The problem can be reproduced on different PC's (Win7x64 pro, i7 and Xeon)

Bernhard

[Bernard]

>>>.Usually debugging thread opens process memory space and overwrites(inserts) the code with int3 opcodes.>>>

If you would like to see it in action you can simply start two instances of windbg.The first will insert the breakpoint at some memory address and next you can attach invasively second instance of the debugger to the first one so you will be able to see debug engine call stack.

[SergeyKostrov]

>>...At least you verified that used breakpoint is translated to 0xCC... I also would like to note that in essence the title of the thread is a little bit incorrect since a 'Breakpoint' action of any Visual Studio can't generate an Illegal Instruction exception and only unsupported instruction could generate it. Unfortunately I can't reproduce it since I don't use Boost at the moment and don't have a system with a CPU which supports AVX2 instruction set. I hope that our generic advises helped you.

[Bernard]

Actually there are some GP exceptions related to int3 and maybe it is possible that OS handler did not properly recognize the exact code meaning of the exception(pushed on the stack by CPU).Altough such scenario seems quite unlikely to happen.

[Bernhard_Zellner]

At least you verified that used breakpoint is translated to 0xCC

I verified, that VS2010 is setting the int3 for the breakpoint at a wrong position. Is is not at the first byte of an opcode. It replaces the third byte of the opcode and that's the reason for getting an illegal instruction exception instead of hitting the breakpoint

correct code:

00c74641 0f439560ffffff  cmovae  edx,dword ptr [ebp-0A0h]

the same code with breakpoint set at byte 3 of opcode:

00c74641 0f43cc          cmovae  ecx,esp
00c74644 60              pushad
00c74645 ff              ???
00c74646 ff              ???

I can reproduce this behaviour on different plattforms and i have the same problem in a much bigger project also in the debug version.

 also inserted by compiler when you have hardcoded breakpoints in your code

I didn't use any hardcoded breakpoints

[Bernard]

Yes you are right.I did not pay attention to this line of code 00c74641 0f43cc.VS debugger should have overwritten  that memory location with one 0xCC and two 0x90 instruction and failed to do so thus trigerred when executed invalid instruction exception.

Try to do the same with windbg and look at the result.

[Bernhard_Zellner]

iliyapolak wrote:

Try to do the same with windbg and look at the result.

This is a good idea. I will try it tomorrow morning at european time :-)

When setting the breakpoint then there is only replaced one byte of the opcode (0x95 with 0xcc).

[SergeyKostrov]

>>...I verified, that VS2010 is setting the int3 for the breakpoint at a wrong position... If this is the root cause of your problem then it has no relation to Intel Compiler 14.0 SP1 and Boost 1.54.

[Bernard]

Hi Bernhard

Usually while overwriting or patching the existed instruction one must take into account the length of the patched instruction.In your case it is 3 bytes and int3 is represented by one byte opcode so the remaining space could be filled with nop or int3 opcodes.

[Bernard]

Sergey Kostrov wrote:

>>...I verified, that VS2010 is setting the int3 for the breakpoint at a wrong position...

If this is the root cause of your problem then it has no relation to Intel Compiler 14.0 SP1 and Boost 1.54.

Yes it seems that there is an error in memory patching/code patching in VS debugger module.It should be further verified and checked with the other debugger(windbg).

[Bernhard_Zellner]

I tried to set in windbg the mentioned breakpoint at line 332. Then i got a box, where windbg offers me 3 addresses which can be used for the breakpoint (WinDbg - Setting breakpoint at line 332.bmp). The first address is the address of the opcode of cmovae with an offset of 2. That is the same address, where VS2010 set the wrong breakpoint. Windgb didn't set the breakpoint to the offered addresses.

[SergeyKostrov]

>>...When setting a breakpoint in the release... I'd like to suggest you a very simple set of tests: Step 1 - Create a new project without any static Boost libraries and make sure that it has the same Compiler and Linker settings as the project with Boost static library ( it could take 5-10 minutes to verify ). Take into account that project settings must be absolutely identical for cases 'Use Microsoft C++ compiler' and 'Use Intel C++ compiler' used in your project with Boost static libraries. Step 2 - Add a couple of very simple code lines, like printf( ... ), _asm NOP and _mm_prefetch( NULL ). For example, a source code for the test could look like: #include "xmmintrin.h" int main( void ) { /* DebugBreak(); */ printf( "Started\n" ); printf( "Step 1\n" ); _asm NOP _asm NOP _asm NOP printf( "Step 2\n" ); _mm_prefetch( NULL ); _mm_prefetch( NULL ); _mm_prefetch( NULL ); printf( "Step 3\n" ); _asm NOP _asm NOP _asm NOP printf( "Step 4\n" ); printf( "Completed\n" ); } Step 3 - Switch to 'Use Microsoft C++ compiler' -> Build both configurations and verify that Breakpoints could be set and working in both Configurations. Step 4 - Switch to 'Use Intel C++ compiler' -> Build both configurations and verify that Breakpoints could be set and working in both Configurations. Step 5 - Uncomment a call to DebugBreak() function and repeat Steps 3 and Step 4. Note 1: In assembler DebugBreak() function should look like: ... int 3 ret ... and simply go through that little function in two steps in order to return to main function. Note 2: A similar set of tests could be repeated for the project with static Boost libraries Note 3: It is possible that you will need to contact Microsoft if that problem is reproducible when 'Use Microsoft C++ compiler' is selected.

[Bernhard_Zellner]

I have to use some boost functions - without this there will be no boost libs linked to the exe.

When i compile my boostserialize project with vs2010 compiler everything works. In this constellation i have no problems.

[SergeyKostrov]

>>I have to use some boost functions - without this there will be no boost libs linked to the exe. >> >>When i compile my boostserialize project with vs2010 compiler everything works. In this constellation i have no problems. In that case a complete VS 2010 test project ( which is set to 'Use Intel C++ compiler' ) needs to be uploaded to the thread to help an Intel Software Engineer with investigation. So, just upload the test project. My understanding is it is possible that there is some incorrect codes generation in Release configuration but it needs to be confirmed on the Intel's side. I still suggest you to complete a set of tests I've recommended as an additional verification.

[SergeyKostrov]

>>...I still suggest you to complete a set of tests I've recommended as an additional verification... If in 'Use Intel C++ compiler' case the exception is thrown in Release or Debug configurations than it is a sign that there is an issue with Intel C++ software.

[Bernard]

It is interesting test,but when running inside VS environment when DebugBreak will be executed the same VS debugger will be notified about the breakpoint exception.The problem lies in patching code section of the running process and  your suggestion does not test any code patching.DebugBreak() function when compiled will be called from the main() and its code(int 0xcc) will not overwrite the other function existing code.

[Bernard]

.>>> Windgb didn't set the breakpoint to the offered addresses.>>>

Can you post which command have you used?

You can also try to write directly memory space of the thread with the help of eb [some address] 0xcc command.

[Bernhard_Zellner]

iliyapolak wrote:

Can you post which command have you used?

I used the gui. I selected one after the other of the addresses in the message box. In the displayed source code i didn't see any red line and i didn't get an error message.

[Bernhard_Zellner]

Sergey Kostrov wrote:

In that case a complete VS 2010 test project ( which is set to 'Use Intel C++ compiler' ) needs to be uploaded to the thread to help an Intel Software Engineer with investigation. So, just upload the test project.

In the first post there is already a testproject attached.

[Bernard]

@Bernhard

Another suggestion is to use debug registers that's mean simply choose to use ba command which will use debug register(DRn) to set the breakpoint.

[Bernard]

Bernhard Zellner wrote:

Quote:

iliyapolak wrote:

Can you post which command have you used?

I used the gui. I selected one after the other of the addresses in the message box. In the displayed source code i didn't see any red line and i didn't get an error message.

Use debugger prompt to enter the breakpoints.

Example:

~ThreadID bp [memory address of cmovae]

You can check pending breakpoints(which are set) with the command bl.

[Bernhard_Zellner]

I have to clarify something.

In this thread i posted a debugging problem with VS2010 and intel compiler 14.0 SP1. I attached a small test project, where the problem can be reproduced exactly with this configuration and set the breakpoint in line 332. This small test project can be posted everywhere in the world. I have the same debugging problem with a much bigger project. But i can't post this project. It belongs to the company. I have to use VS2010 for my debugging and i would like to debug on source level, not on assembler level.