Bugged

[billroper]

I'm fixing up some serialization code that makes heavy use of C++ templates. Unfortunately, there's something not quite right with what's happening so I'm having to trace through it with the debugger to figure out what's going on.

This makes it very annoying when I tell the debugger to single step and instead it goes flying off somewhere at random, usually into the exception throw that I'm trying to find out the cause of. I can work around this by judicious use of breakpoints, but I really hate it when the debugger decides to misbehave.

*sigh*

Comments

[poltr1]

I feel your pain. I was running into the same problem stepping through Perl code on Eclipse using the EPIC plug-in and whatever module I loaded to view global variables. I couldn't see the variables, or it would go off into never-never-land.

[madfilkentist]

Sounds like the Heisenberg Uncertainty Principle of debugging. The more precisely you know what the state of your variables is, the less precisely you can know where you are.

[kevinnickerson.livejournal.com]

Happily, our exception throws (at least in debug builds) show the call stack. Not sure how, they were setup by someone else before I got moved from 'real programming' to C++/.NET.

Overall, I'm not a fan of the throw statement, I think it's overused. That's Religion though.

[billroper]

I get the call stack when the exception is thrown. The problem is that before the exception is actually thrown, I get a string handling error that has no useful call stack at all. And what I really want to see is the state of the data just before the exception is thrown.

So I breakpoint away...

[filkermanque.livejournal.com]

Is anyone masking off interrupts where the debugger runs away?

[billroper]

Not that I know of. The debugger works normally in this neighborhood for some of the template types, but not all. *sigh*

[filkermanque.livejournal.com]

As a debugger developer, I like to blame the compiler first. :-)