Can't debug into method

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.

publicaciones de 27 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Hi, A clarification is needed:

>>...if ( false == methodA() )

Is methodA() declared as a function or as a method of some class?

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.

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

>>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.

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.

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

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.

Hi Sergey,

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

I don't know why.

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

>>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.

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.

>>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.

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()].

Adjuntos: 

AdjuntoTamaño
Descargar stepinmethod.zip10.54 KB

>>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.

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

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 [c]
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 [c]
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 (!).

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 ]


[ Microsoft C++ compiler ]

Adjuntos: 

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
...

Adjuntos: 

AdjuntoTamaño
Descargar stepintomethod.zip11.33 KB

Hi Sergey and Georg

Thank you for your support.

When this problem is solved, please let me know.

Best Regard

I understood that you're trying to use Run-Time Binding ( or Late Binding ) of different C++ objects. Is that correct? If Yes, the current output ( 1 ):

[ Output 1 ]
...
Main start
D::MyMethod
D::MyMethod
D::MyMethod
Main end
...
looks strange for me and I would expect a different output ( 2 / simulated ):

[ Output 2 ]
...
Main start
D::MyMethod
B::MyMethod
C::MyMethod
Main end
...
If this is what you actually want to do then your test case could be implemented in a different way. Please confirm what output do you want to see, 2 or 1?

Hi Sergey

I understand what you mean. In this sample, Output must be:

Main start
D::MyMethod
D::MyMethod
D::MyMethod
Main end

But I wonder why I can't step in with statement [c->MyMethod()] with Intel complier but with Visual Complier I can step in.

Best Regard 

>>...I wonder why I can't step in with statement [c->MyMethod()] with Intel complier...

>>>>[ Posted by Georg ]
>>>>...I think this is related to incorrect debug information generated by the compiler. Hence, I've created a defect
>>>>ticket (DPD200321626)...

This is what Georg posted a couple of hours ago and it will be fixed.

>>...In this sample, Output must be:
>>
>>Main start
>>D::MyMethod
>>D::MyMethod
>>D::MyMethod
>>Main end

I see. Here is a very small test case I just created that uses Virtual Base classes. Please take a look, or ignore if you don't need it :).
...
#include "stdio.h"

class A
{
public:
A(){};
virtual ~A(){};
virtual bool MyMethod() = 0;
};

class B : virtual public A
{
public:
B(){};
virtual ~B(){};
virtual bool MyMethod();
};

bool B::MyMethod()
{
printf( "B::MyMethod\n" );
return true;
}

class C : virtual public A
{
public:
C(){};
virtual ~C(){};
virtual bool MyMethod();
};

bool C::MyMethod()
{
printf( "C::MyMethod\n" );
return true;
}

class D : public B, public C
{
public:
D(){};
virtual ~D(){};
virtual bool MyMethod();
};

bool D::MyMethod()
{
printf( "D::MyMethod\n" );
return true;
}

int main( void )
{
printf( "Main start\n" );

A *d = ( D * )new D();
A *b = ( B * )new B();
A *c = ( C * )new C();

d->MyMethod();
b->MyMethod();
c->MyMethod();

printf( "Main end\n" );

return ( int )0;
}

[ Output ]
Main start
D::MyMethod
B::MyMethod
C::MyMethod
Main end

Note: This is almost a book-like application of Late Binding of C++ objects...

Hi everybody,

Georg, please take a look at another test-case and it is based on a code provided by Ha Duy Tuan. Even if the Run-time Binding is used in a different way the test also reproduces 'Cant Step Into the Method' problem.

Adjuntos: 

AdjuntoTamaño
Descargar rtbtestapp.zip3.88 KB

Hello,

a fix has been made. Unfortunately it won't make it in the 2013 releases. That means, only with the next major Intel(R) Composer XE package released somewhere end of 2014 it will show up. You can set manual breakpoints as (admittedly inconvenient) workaround in the meantime.

Best regards,

Georg Zitzlsberger

Hi Georg,

Thanks for your information.

Best regards,

Ha Duy Tuan

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya