186 Programming “It Can’t Be a Bug, My Makefile Depends on It!” The programmers at BBN were generally the exception. Most Unix pro- grammers don’t fix bugs: most don’t have source code. Those with the code know that fixing bugs won’t help. That’s why when most Unix pro- grammers encounter a bug, they simply program around it. It’s a sad state of affairs: if one is going to solve a problem, why not solve it once and for all instead of for a single case that will have to repeated for each new program ad infinitum? Perhaps early Unix programmers were closet metaphysicians that believed in Nietzche’s doctrine of Eternal Recurrence. There are two schools of debugging thought. One is the “debugger as phy- sician” school, which was popularized in early ITS and Lisp systems. In these environments, the debugger is always present in the running program and when the program crashes, the debugger/physician can diagnose the problem and make the program well again. Unix follows the older “debugging as autopsy” model. In Unix, a broken program dies, leaving a core file, that is like a dead body in more ways than one. A Unix debugger then comes along and determines the cause of death. Interestingly enough, Unix programs tend to die from curable diseases, accidents, and negligence, just as people do. Dealing with the Core After your program has written out a core file, your first task is to find it. This shouldn’t be too difficult a task, because the core file is quite large— 4, 8, and even 12 megabyte core files are not uncommon. Core files are large because they contain almost everything you need to debug your program from the moment it died: stack, data, pointers to code… everything, in fact, except the program’s dynamic state. If you were debugging a network program, by the time your core file is created, it’s too late the program’s network connections are gone. As an added slap, any files it might have had opened are now closed. Unfortunately, under Unix, it has to be that way. For instance, one cannot run a debugger as a command-interpreter or trans- fer control to a debugger when the operating system generates an excep- tion. The only way to have a debugger take over from your program when

“It Can’t Be a Bug, My Makefile Depends on It!” 187 it crashes is to run every program from your debugger.2 If you want to debug interrupts, your debugger program must intercept every interrupt and forward the appropriate ones to your program. Can you imagine running an emacs with three context switches for every keystroke? Apparently, the idea of routine debugging is alien to the Unix philosophy. Date: Wed, 2 Jan 91 07:42:04 PST From: Michael Tiemann cygint!tiemann@labrea.stanford.edu To: UNIX-HATERS Subject: Debuggers Ever wonder why Unix debuggers are so lame? It’s because if they had any functionality at all, they might have bugs, and if they had any bugs, they might dump core, and if they dump core, sploosh, there goes the core file from the application you were trying to debug. Sure would be nice if there was some way to let applications control how and when and where they dump core. The Bug Reliquary Unlike other operating systems, Unix enshrines its bugs as standard operating procedure. The most oft-cited reason that Unix bugs are not fixed is that such fixes would break existing programs. This is particularly ironic, considering that Unix programmers almost never consider upward compatibility when implementing new features. Thinking about these issues, Michael Tiemann came up with 10 reasons why Unix debuggers overwrite the existing “core” file when they them- selves dump core: Date: Thu, 17 Jan 91 10:28:11 PST From: Michael Tiemann tiemann@cygnus.com To: UNIX-HATERS Subject: Unix debuggers David Letterman’s top 10 weenie answers are: 10. It would break existing code. 9. It would require a change to the documentation. 8. It’s too hard to implement. 2Yes, under some versions of Unix you can attach a debugger to a running program, but you’ve still got to have a copy of the program with the symbols intact if you want to make any sense of it.