Previous: Quitting the BASH debugger, Up: Invocation [Contents][Index]
Running a program from the debugger adds a bit of overhead and slows
down your program quite a bit. Addressing this better would mean some
serious changes to BASH internals, and judging from experience
in other languages there still the slowdown is still noticeable. If
you have a configure
script generated by autoconf, and you want
to stop in the middle of the script, it can take quite a while.
Furthermore, by necessity, debuggers change the operation of the program they are debugging. And this can lead to unexpected and unwanted differences. It has happened so often that the term “Heisenbugs” (see http://en.wikipedia.org/wiki/Heisenbug) was coined to describe the situation where the addition of the use of a debugger (among other possibilities) changes behavior of the program so that the bug doesn’t manifest itself anymore.
There is another way to get into the debugger aside from calling bashdb from the outset, and this adds no overhead or slowdown until you reach the point at which you want to start debugging. However for this method you must change the script. Because the debugger isn’t involved before the first call, there is no overhead; the script will run at the same speed as if there were no debugger up to the point where it is first invoked.
• Debugging a Running Shell Script: | ||
• Program-Controlled Line Tracing: |