Subject: [Announcement:] debugging/preventing poltergeist Date: Wed, 21 Mar 2001 11:22:13 -0500 From: Igor Markov Organization: U. of Michigan, EECS Newsgroups: umich.eecs.class.380 This is a response to several recent postings, which essentially complain of poltergeist (i.e., supposedly a very minor change or no change at all caused strange error messages/problems). The two main approaches to debugging/preventing poltergeist are (i) replication of poltergeits with the smallest possible amount of code. First try to replicate the original observation (same system, same compiler, etc), and if the problem never not shows up, it could have been a false alarm. Then try to make sure that the problem is in your code and not in the system/compiler/hardware (e.g., the most mysterious compiler errors I saw were due to faulty memory chips) -- by running on anythe system, and reinstalling/recompiling from scratch. Eventually, resort to binary search, and when you are looking at 10 lines of code or less, problems may become obvious. (ii) revision control (is indispensible for a hundred more reasons). The idea here is that if your code is in a good shape, remove all binary files produced from source code and save the whole package as, say, revision 0.1. Then, in a couple of hours (or in a day), save revision 0.2 and start working on revision 0.3. If you observe poltergeist in revision 0.3, you can restore 0.2 from backup, identify all changes and roll them back one by one. A number of tools with varying degrees of fanciness exist to automate this process (CVS, RCS, SCCS, Clear Case, etc), but EECS 380 projects are too simple/small to warrant learning those. You can just copy whole directories (recursively) with cp -R, e.g., cp -R rev0.2 rev0.3 -- Igor Markov (734) 936-7829 EECS 2211 http://www.eecs.umich.edu/~imarkov