Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpda!hpcuhb!hpindda!atchison
From: atchison@hpindda.HP.COM (Lee Atchison)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think C 3.0 Bug?
Message-ID: <7390013@hpindda.HP.COM>
Date: 7 Sep 88 19:02:56 GMT
References: <2998@mit-amt>
Organization: HP Information Networks, Cupertino, CA
Lines: 61

I ran into almost this exact same problem on at least two occasions.  I
would get a bomb, usually (but not always) with the debugger saying
something like "Illegal Instruction" or "Odd Address".  The problem in
my case was that I was passing (by reference) a local variable to
a Mac Routine that wasn't declared correctly.  In particular, the variable
I passed was a structure of the wrong type (the structure I declared was
smaller than the structure the Mac Routine was expecting).  What happened
was the Mac routine (it was a toolbox routine) wrote beyond the end of
the structure and overwrote part of my stack.  This caused references to
other local variables to go haywire, and occasionally, the return value
to be messed up, so that when I returned from the current routine, I'd
get the Illegal Instruction or Odd Address error.

Like I said, I've had this problem show up on at least two occasions, and
both times it was the same cause -- my program messed up.

This is a sample code segment that could cause the problem:

typedef struct { .... } atype,*Patype,**Hatype;

routine(a,b)
	int *a,*b;
{
	Patype avariable;

	ToolBoxRoutine(&avariable); /* Expects an atype "passed by reference" */

	...other code...

}


It would crash when I tried to access a or b in the "...other code...", or
when I tried to return from this routine (return value overwritten).
The code should be written as:

typedef struct { .... } atype,*Patype,**Hatype;
routine(a,b)
	int *a,*b;
{
	atype avariable;	/* NOT Patype */

	ToolBoxRoutine(&avariable); /* atype passed by reference */

	...other code...
}

This, of course, is a dumb mistake, but an easy mistake to make, and a
hard mistake to catch.  But it will DEFINITELY cause the problems you
are seeing.

I found it by single stepping with the debugger and waiting for it to
crash, then look at the declarations in the rouine it crashed in.

Hope this helps.

			-lee
----
Lee Atchison
Hewlett Packard, Business Networks Division
Cupertino, CA 95014
atchison%hpindda@hplabs.hp.com