topic Debugging faulty applications using IPP in Intel® Integrated Performance Primitives

Debugging faulty applications using IPP

simonjrichter — Tue, 24 Jan 2012 07:08:04 GMT

Hi,

I appear to have made a small mistake in one of my applications, and passed an invalid pointer. Unfortunately, the call stack only lists IPP and, a few frames down, one of the framework classes; the code that is actually at fault is not shown, as the stack cannot be decoded.

I can sort of work around the problem by manually adjusting the stack pointer in the debugger, but I am wondering if there was a way to get the debugger to understand the stack.

Simon

Debugging faulty applications using IPP

Sergey_K_Intel — Tue, 24 Jan 2012 08:28:01 GMT

Hi Simon,

Are you executing a debug version of your application ("-g" for Linux, "/Od /Zi" for Windows) ?

Regards,

Sergey

Debugging faulty applications using IPP

simonjrichter — Tue, 24 Jan 2012 09:47:43 GMT

Hi Sergey,

yes, I am. When I manually unwind the stack, I can go back to my code and fully debug it; however the IPP library does not come with unwind information, so the debugger cannot walk the stackhere, so it resorts to scanning the stack for something that resembles a valid stack frame.

Simon

Debugging faulty applications using IPP

Sergey_K_Intel — Tue, 24 Jan 2012 11:49:00 GMT

Simon, could you show several lines of stack dump? As far as I remember, stack dump is almost always ok, except when application crashes within threaded IPP function. In this case, on Windows for example, the top of stack often points to NT DLLs or some other system DLLs.

Sergey

Debugging faulty applications using IPP

simonjrichter — Tue, 24 Jan 2012 12:55:45 GMT

Sergey,

sure:

ippsp8-7.0.dll!105ec0c7()
[Frames below may be incorrect and/or missing, no symbols loaded for ippsp8-7.0.dll]
ippsp8-7.0.dll!1044daea()
CalcSequence.dll!CSequence::run() Line 2143 + 0xd bytes C++

[...]

CSequence is a container that keeps a list of pointers to objects that represent individual actions, "run()" invokes these in turn. What is missing between the last undecoded stack frame from IPP and the first one shown is at least one virtual method call.

Simon

Debugging faulty applications using IPP

SergeyKostrov — Tue, 24 Jan 2012 15:01:24 GMT

Quoting simonjrichter

Sergey,

sure:

ippsp8-7.0.dll!105ec0c7()
[Frames below may be incorrect and/or missing, no symbols loaded for ippsp8-7.0.dll]
ippsp8-7.0.dll!1044daea()
CalcSequence.dll!CSequence::run() Line 2143 + 0xd bytes C++

A message clearly shows you that 'no symbols loaded for ippsp8-7.0.dll'.

You need a pdb-file for the DLL you're trying to debug or step-intoin order to see all symbols, etc.

Microsoft providesadditional Debug Symbols packsfor all Windows operating systemswith pdb-files
for almost all system DLLs and when installedmore details are seen in a Debugger.

Intel doesn't provide it for IPP, correct?

I would bettertry to find a piece of code "responsible" for a problem.

Best regards,
Sergey

Debugging faulty applications using IPP

simonjrichter — Tue, 24 Jan 2012 15:46:26 GMT

Sergey,

I am aware that there are no PDB files for IPP (which is a true shame, as it is certainly possible to strip these down to just the bare minimum needed to unwind a stack in the presence of variable length stack frames). PDBs for all system libraries and project DLLs are already present.

As I'm fairly certain that others have had the same problem, I'd be interested if there is a known workaround. During the course of two hours, I could manually unwind the stack by following frame pointers (and some guessing for fixed-size frames) -- but I hardly think this is a viable approach should I ever run into this problem again.

Simon

Debugging faulty applications using IPP

Sergey_K_Intel — Tue, 24 Jan 2012 16:13:39 GMT

Simon, is it essential, that you debug your application with dynamic IPP linking?

I would start debugging with static linking to merged IPP libraries (ipp*_l.lib) and, after application gets OK, just would turn on dynamic libs. There is nothing special happening with the stack, the only feature is smart dispatching, when a call to a generic IPP function is passed via simple JUMP to the function specific for current CPU architecture (like p8 = "SSE4.1 in 32-bit" mode in your case).

If the size of application under debug is critical, you can inlude "ipp_p8.h" instead of plain ipp.h and link your application to the merged static libraries (*_l). Then linker will take function clones specific for P8 architecture. The function names will have p8_ or v8_ (if there is no p8_ version) prefixes in their names.

Regards,

Sergey

Debugging faulty applications using IPP

simonjrichter — Tue, 24 Jan 2012 17:21:39 GMT

Sergey,

if those libraries contain the necessary debug information to give proper stackframes, it might be worth a shot. I can try this tomorrow (I've been at work for 12 hours straight staring at hexdumps).

Thanks,
Simon

Debugging faulty applications using IPP

SergeyKostrov — Wed, 25 Jan 2012 02:06:16 GMT

Take a break, Simon!

PS:
Could you provide more technical information, like:

Did your application crash?
Did you have an Access Violation?
What IPP functions are you using?
Did you try to comment some pieces of codes in order to find a "bad code", instead of debugging?

Best regards,
Sergey