erci18@castle.ed.ac.uk (A J Cunningham) (12/01/89)
I've been trying to debug a program which implements the pinkbook protocol for Macs. Unfortunately when I try running it I get a crash which results in the Mac being completely locked up. The programmer's switch doesn't help (aside form rebooting) and I can't get into the debugger. (This happens with both SADE and MacsBug.) Can anyone recommend a debugger which is more resilient to this sort of occurence? Are there any hardware assisted debuggers for the mac? Tony Cunningham -- Tony Cunningham, Edinburgh University Computing Service. erci18@castle.ed.ac.uk "If the thunder don't get ya then the lightnin' will."
oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/03/89)
The most common cause of complete lockup of the Macintosh by buggy programs
is:
Copying arbitrary data into low memory, for example:
char *src, dest;
src = "\pGuaranteed to Clobber the Interrupt Vector Table.";
dest = NIL;
BlockMove(src, dest, (long) (unsigned char) src[0]);
You can check for this by setting MacsBug to checksum a location in low
memory after every instruction. You might want to set Debugger()
statements throughout your program to home in on the suspect code. (Put a
debug statement in the middle, run it. If it crashes before it hits the
middle, you know the problem is in the first half...)
There is currently a market niche for a product that to reprogram the MMU
on those macs that have one to let the programmer declare a block of
addresses as READ-ONLY, and generate an interrupt to the debugger when an
instruction trys to store there.
Since most Mac programs store data in handles and in movable code segments
(which are also handles) such a tool would not be ideal (It would get in
the way of normal heap motion.), but it would at least solve the
low-memory clobber problem.
--- According to the Constitution, the Constitution is unconstitutional:
--- David Phillip Oster --U.S.Constitution I.10.1: "No State shall
Arpa: oster@dewey.soe.berkeley.edu --enter into any treaty, alliance, or
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu -- confederation..."jamesm@sco.COM (James M. Moore) (12/05/89)
In airteagal <32962@ucbvax.BERKELEY.EDU>, scriobhann oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster): >The most common cause of complete lockup of the Macintosh by buggy programs >is: > >Copying arbitrary data into low memory, for example: My favorite way (discovered last night) is to be really lazy about allocation of variables, and put too much stuff on the stack. I was allocating 2048 byes of chars (char bigstring[2048]) on entry into a method, and whenever I entered the method I got a message from Multifinder saying my application had quit unexpectedly. At that point, the mouse was usually frozen, and I had to reboot. Yes, I know this is a dumb thing, and I should have caught it immediately. And needless to say the code doesn't do this anymore. Still, I burned at least an hour and a half finding the thing, mostly because I also managed to corrupt the resource file when it went down. If you corrupt your resource file, TCL tends to crash before you get into your own code. Easy to fix once you figure out what's going on. -- James Moore | Nil aon .sig maith agam anois - Santa Cruz Operation UNIX Tech Support | B'fheidir an tseachtaine seo jamesm@sco.com | chugainn.