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