Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!uc!noc.MR.NET!msi.umn.edu!umeecs!umich!caen!math.lsa.umich.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!sun-barr!ccut!s.u-tokyo!rkna50!nttlab!icot32!kddlab!atrpost!atr-hr!alain
From: alain@atr-hr.atr.co.jp (Alain de Cheveigne)
Newsgroups: comp.sys.mac.programmer
Subject: Re: 'am I dead yet?', or, debugging
Message-ID: <2322@atr-hr.atr.co.jp>
Date: 26 Oct 90 05:48:31 GMT
References: <15998@csli.Stanford.EDU> <1990Oct25.174509.10250@eng.umd.edu>
Organization: ATR Auditory and Visual Perception Research Labs., Kyoto, JAPAN
Lines: 57
In-reply-to: russotto@eng.umd.edu's message of 25 Oct 90 17:45:09 GMT


In article <1990Oct25.174509.10250@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes:

>In article <15998@csli.Stanford.EDU> ramaley@csli.Stanford.EDU (Alan Ramaley) writes:
...
>>The program has grown beyond the point of comprehension.  I would step
>>through with the debugger, but the problem could be anywhere, and it
>>usually takes five minutes or so to show up.
...
>>I'm sure this kind of program-sprawl-can't-find-the-offending-code
>>problem has struck others.  Could you share your solutions?
>
>
>Things get much better if you can localize the crash to a set of procedures--
>I think that using the profile code, you can get a list of procedures 
>executed to be output.  

In my experience its not that useful to know what the program was doing
just before the crash.  A typical bug causes some random bit of memory
to be crushed (for example writing beyond the end of an array, or to
where a handle block was supposed to be but isn't).  The program trips 
on it and crashes, often much later.  Knowing exactly when and how this
happens often gives little indication as to where the real bug is.

The only solution I know (beyond choosing another way in life...) is to
double-check the code, especially for things like unlocked handles.  
I've found the following macro to be useful:

#define CHECK_EM  1  /* if true, validity tests are performed */

#if CHECK_EM
#define CHECKLOCK(h) checkLock((Handle) h,#h,__FILE__,__LINE__)
#else
#define CHECKLOCK(h) 		
#endif

You just insert a CHECKLOCK() everytime you need to be *sure* a handle is 
locked (particularly where you *are* sure it is...).  There is ultimately no 
performance penalty because you can undefine CHECK_EM once the
program is fully debugged.

The checkLock() function checks the state of the handle, in addition
to doing a whole set of sanity checks:
* is the handle address non-nil, and even?
* does it point within either system or application heap?
* does it point within the zone it says it belongs to (using HandleZone())?
* is the master pointer non-nil and even?
* does it point within the same zone as the handle ?
* does RecoverHandle() return the handle itself ?

I'll post this and other functions and macros if there is interest, 
and if some guru (maybe at Apple?) agrees to look them over first
(are SysZone and ApplZone ok to use?  How about MemTop?).


Alain de Cheveigne
alain@atr-hr.atr.co.jp