From: chuck@gte.com (Chuck Hoffman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Help!  System error #28
Date: 13 Aug 92 14:02:49 GMT
Followup-To: comp.sys.mac.programmer
Organization: GTE Laboratories

Thanks to all.  These replys came to my e-mail.

-Chuck Hoffman

I'm not sure why we're here, but I am sure that while we're here we're
supposed to help each other.

======================================
From robichau@lambda.msfc.nasa.gov Wed Aug 12 13:14:12 1992

"Stack has moved into application heap" is an accurate description of
your problem. I recently suffered through a similar problem, so let me
see if I can pass along the useful explanations I got.

The stack grows up from low memory, and the heap grows down from high
memory. If the zone size of your application is less than the sum of
the stack and heap sizes, you'll collide as soon as you cause the
stack to grow too much.

Deeply nested routines, or lots of local procedure variables, are
frequent culprits.

To fix this, make sure that your SIZE resource is correct. For
example, I had a 128k stack and a 640k application heap in a 512k
partition. Boom!

Also be careful about static allocation of large structures. Dynamic
allocation _with NewHandle & NewPtr_ is the way to go whenever
possible.

Good luck, and hope this helps.

-Paul

======================================
From robichau@lambda.msfc.nasa.gov Wed Aug 12 15:02:34 1992

Many Toolbox operations return error codes when they interrupt operations
due
to a lack of RAM. QuickDraw, on the other hand, fails spectacularly in some
cases and fails quietly in others.

I'm not sure about the File Manager routines. Try increasing the
application
size again (to give your app more memory; remember the guidelines in my
last
message) and keep on truckin'.

Regards,
-Paul

======================================
From zben@ni.umd.edu Wed Aug 12 16:34:16 1992

Both 28 and 25 make sense if you're just using more memory than
is available in your stack frame.  In one case the stack grows
into the heap, in the other case the heap grows into the stack.
It's the same problem, but you get different error codes
depending on who detects it first.

======================================
From d88-jwa@nada.kth.se Wed Aug 12 17:03:36 1992

You're probably zapping memory, like not passing a large
enough buffer, or passing a long count instead of a pointer
to one, or whatever.

Turn on "require prototypes" and turn off "simplyfy prototypes"
in Mac#Includes.c and recompile your MacHeaders and then your
project.

======================================
From julen@inf.ethz.ch Thu Aug 13 04:30:08 1992

hi!

possible reasons include:
1) recursion somewhere, probably with local variables...
2) you are not giving back all the memory you allocate. use a global
varibale to keep track of the total ram allocated (ie each time you
allocate you add the size to the var, each time you dispose, you decrement
the var). test the counter just before the crashing fsread, so you can
check it from inside macsbug. it would look something like: (in pascal,
similiar in c)

if globalcounter <> 0 then;
fsread (...)

and from inside macsbug:

TST.L -xxx(A5)
...
JSR fsread

you can then test the counter with
dm a5-xxx

hope this helps ;-)

--markus