Setting breakpoints alters program behavior?
I've got a (C++, Carbon) command line tool that I'm debugging that uses libxml2 to generate XML.
Every now and then, it will print an error message "xmlEscapeEntities: char out of range" while it is processing input.
Since the input is fairly large, and I'm not sure exactly what input it is complaining about, I looked at the libxml sources, and discovered that there is a routine named "xmlGenericError" which is called to print out the error. So, when I was debugging the tool (in Xcode), I stopped at the beginning of the run, and set a breakpoint at xmlGenericError.
That certainly didn't work - now the tool crashes (about 1/2-way through the input) with an EXC_BAD_ACCESS error, deep in the bowels of libxml.
This is 100% reproducible - w/o the breakpoint the program runs, with one or two messages appearing on the console. With the breakpoint set, the program crashes.
What gives?
P.S. I once worked with a debugger that wouldn't let you set breakpoints in shared libraries until after "they had been loaded", so I set a second breakpoint in the program (after several calls to libxml had been made), and set the breakpoint on xmlGenericError at that point. No change.
Update (11/01) It turns out that "xmlGenericError" is a variable, not a function - it's a pointer to an error handling function.
Setting the breakpoint on the function made Xcode/GDB _much_ happier. I can't help but think that it could have _told me_ that I was trying to set a breakpoint on a variable, and maybe that wasn't what I meant.
Oh, well, this is Unix.
posted by Marshall @ 11:20 AM
2 comments
