Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
9 Views

Can't debug into method

Hi all

I'm using Intel Parallel 2011.

I can't debug into methodA with below statement when I press F11:

if (false == methodA())

But if I set break point inside methodA, I can debug into this method.

Anybody met this problem.

0 Kudos
26 Replies
Highlighted
Valued Contributor II
9 Views

Hi, A clarification is needed: >>...if ( false == methodA() ) Is methodA() declared as a function or as a method of some class?
0 Kudos
Highlighted
Beginner
9 Views

Hi, the fact that I had class B inherit class A.

In class A, I defined methodA(), and in class B, methodA is overrided.

And from methodB of classA, I called above statment, and in this case methodA of class B will be called.

And I can't step into methodA of class B.

0 Kudos
Highlighted
Employee
9 Views

Hello, it seems you compiled with optimizations turned on (/O1 and higher). This is expected as the compiler can restructure/change code according to various optimizations strategies. When debugging optimized code, it seems rather chaotic (e.g. stepping is not linear, functions are not available at all, etc.), but that's OK. Please compile with no optimizations when debugging, if possible. Or expect "unexpected" behavior while debugging. Btw.: We have a dedicated debug solutions forum for such questions here: http://software.intel.com/en-us/forums/debug-solutions/ Best regards, Georg Zitzlsberger
0 Kudos
Highlighted
Valued Contributor II
9 Views

>>I can't debug into methodA with below statement when I press F11: >> >>if ( false == methodA() ) >>... If some optimization option ( as Georg suggested /O1 ) was used, and methodA() is always returning false then it is possible that the binary code for that if statement simply doesn't exists. Check source codes of methodA() method.
0 Kudos
Highlighted
Beginner
9 Views

Hi Georg and Sergey

Thanks for your answer.

But I'm setting Optimization = Disabled (/Od) in Debug mode.

And About:

>>methodA() is always returning false

In parent class, it always returning true.

But in implement class, I'm overriding this method, some cases returning false, and some cases returning true.

In this case, it will call methodA of implement class.

It's strange that If I set break point in methodA of implement class, I can step into this method.

Do you have any advice?

Best Regards.

0 Kudos
Highlighted
Employee
9 Views

Hello, if optimizations are off for both the caller and callee (both can be in different compilation units) and setting breakpoints works for the method it looks like a bug -- either from the compiler or debugger. To continue investigation I'd need some (simple) case to reproduce. Would it be possible to shrink this down to some code snippet you can share? Thank you & best regards, Georg Zitzlsberger
0 Kudos
Highlighted
Valued Contributor II
9 Views

Please do a verification with Microsoft C++ compiler in order to see if step-into the code works. If it does work then then you're dealing with some Intel C++ compiler issue.
0 Kudos
Highlighted
Beginner
9 Views

Hi Sergey,

If I use Microsoft C++ compiler, I can step in without problem, but in Intel C++ compiler.

I don't know why.

0 Kudos
Highlighted
Beginner
9 Views

Hi Georg and Sergey

I use "public virtual" keyword to inheriting like.

ClassB: public virtual ClassA

ClassC: public virtual ClassA

ClassD: public ClassB, public ClassC

Did you met any problem for debugging when using "public virtual" keyword before?

Thanks

0 Kudos
Highlighted
Valued Contributor II
9 Views

>>I use "public virtual" keyword to inheriting like. >> >>ClassB: public virtual ClassA >> >>ClassC: public virtual ClassA >> >>ClassD: public ClassB, public ClassC >> >>Did you met any problem for debugging when using "public virtual" keyword before? It looks like something is wrong. Once again, could you post a complete test case since it will save time of Intel software engineers? Thanks in advance.
0 Kudos
Highlighted
Beginner
9 Views

Hi Sergey and Georg

I'm sorry to trouble both of you.

I'm trying to reappear this problem in new project and send to both of you.

But it seems that this problem doesn't happen in small size code.

0 Kudos
Highlighted
Valued Contributor II
9 Views

>>I'm sorry to trouble both of you. >> >>I'm trying to reappear this problem in new project and send to both of you. Please post a test-case as soon as it is ready. Thanks in advance.
0 Kudos
Highlighted
Beginner
9 Views

Hi Sergey and Georg

I send to both of you source code that happening this problem.

I'm using Intel Parallel 2011 update 1.

In main.cpp file, can step in [d->MyMethod()] and [b->MyMethod()], but can't not step in [c->MyMethod()].

0 Kudos
Highlighted
Valued Contributor II
9 Views

>>I send to both of you source code that happening this problem. >> >>I'm using Intel Parallel 2011 update 1. >> >>In main.cpp file, can step in [d->MyMethod()] and [b->MyMethod()], but can't not step in [c->MyMethod()]. Thank you and I'll post results of my investigation some time later.
0 Kudos
Highlighted
Employee
9 Views

Hello, thank you very much for the great reproducer! It helped to reproduce the issue on our side very fast. I think this is related to incorrect debug information generated by the compiler. Hence, I've created a defect ticket (DPD200321626). As soon as it's fixed I'll let you know. Best regards, Georg Zitzlsberger
0 Kudos
Highlighted
Valued Contributor II
9 Views

Thank you for the reproducer. I've done investigation and I would split my results into two parts. Part 1: Confirmation of 'Can't step into the method' issue Reproduced the problem with Intel C++ compiler 13.0.089 ( Initial Release ) integrated with Visual Studio 2008 Professional Edition. Even if both executables displayed identical outputs ( I added printf calls for all 'MyMethod' methods ) something is wrong when debugging is done with executable created by Intel C++ compiler. However, debugging in Disassembler Window worked well and I was able to step into the last call. Also, please compare assembler codes generated by both C++ compilers for c->MyMethod() call: [ Intel C++ compiler ] ... 000C1975 movzx eax,byte ptr [ebp-0B9h] 000C197C test eax,eax 000C197E jne 000C1990 000C1980 push eax 000C1981 mov dword ptr [esp],offset std::_Iosb::badbit+90h (0CA104h) 000C1988 call _RTC_UninitUse (0C25A0h) 000C198D add esp,4 000C1990 mov byte ptr [ebp-0B6h],1 000C1997 mov eax,dword ptr 000C199A mov dword ptr [ebp-2Ch],eax 000C199D movzx eax,byte ptr [ebp-0B6h] 000C19A4 test eax,eax 000C19A6 jne 000C19B8 000C19A8 push eax 000C19A9 mov dword ptr [esp],offset std::_Iosb::badbit+94h (0CA108h) 000C19B0 call _RTC_UninitUse (0C25A0h) 000C19B5 add esp,4 000C19B8 movzx eax,byte ptr [ebp-0B6h] 000C19BF test eax,eax 000C19C1 jne 000C19D3 000C19C3 push eax 000C19C4 mov dword ptr [esp],offset std::_Iosb::badbit+94h (0CA108h) 000C19CB call _RTC_UninitUse (0C25A0h) 000C19D0 add esp,4 000C19D3 mov eax,dword ptr [ebp-2Ch] 000C19D6 mov eax,dword ptr [eax] 000C19D8 mov eax,dword ptr [eax] 000C19DA mov edx,esp 000C19DC mov dword ptr [ebp-20h],edx 000C19DF mov edx,dword ptr [ebp-2Ch] 000C19E2 mov ecx,edx 000C19E4 call eax 000C19E6 mov byte ptr [ebp-0B3h],al 000C19EC mov eax,dword ptr [ebp-20h] 000C19EF cmp esp,eax 000C19F1 call _RTC_CheckEsp (0C1D70h) ... Note 1: However, I was able to step into the method from Disassembler Window. [ Microsoft C++ compiler ] ... 010517C5 mov eax,dword ptr 010517C8 mov edx,dword ptr [eax] 010517CA mov esi,esp 010517CC mov ecx,dword ptr [c] 010517CF mov eax,dword ptr [edx] 010517D1 call eax 010517D3 cmp esi,esp 010517D5 call @ILT+365(__RTC_CheckEsp) (1051172h) ... Note 2: I was able to step into the method from Source Codes and Disassembler Windows. Note 3: The code generated by Microsoft C++ compiler is more compact (!).
0 Kudos
Highlighted
Valued Contributor II
9 Views

Part 2: Verification of objects in a Watch Window for Intel and Microsoft C++ compilers I have not detected any problems and please compare tree views: [ Intel C++ compiler ]
cantstepintoicc.jpg
[ Microsoft C++ compiler ]
cantstepintoicc.jpg
0 Kudos
Highlighted
Valued Contributor II
9 Views

A modified test-case attached. Outputs for both executables are as follows: [ Intel C++ compiler ] ... Main start D::MyMethod D::MyMethod D::MyMethod Main end ... [ Microsoft C++ compiler ] ... Main start D::MyMethod D::MyMethod D::MyMethod Main end ...
0 Kudos
Highlighted
Beginner
9 Views

Hi Sergey and Georg

Thank you for your support.

When this problem is solved, please let me know.

Best Regard

0 Kudos