home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / mac / programm / 13935 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!usc!sol.ctr.columbia.edu!samsung!transfer!ceylon!choffman.gte.com!user
  2. From: chuck@gte.com (Chuck Hoffman)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Help!  System error #28
  5. Message-ID: <chuck-130892100803@choffman.gte.com>
  6. Date: 13 Aug 92 14:02:49 GMT
  7. References: <chuck-120892123052@choffman.gte.com>
  8. Sender: news@ceylon.gte.com
  9. Followup-To: comp.sys.mac.programmer
  10. Organization: GTE Laboratories
  11. Lines: 100
  12.  
  13. Thanks to all.  These replys came to my e-mail.
  14.  
  15. -Chuck Hoffman
  16.  
  17. I'm not sure why we're here, but I am sure that while we're here we're
  18. supposed to help each other.
  19.  
  20. ======================================
  21. From robichau@lambda.msfc.nasa.gov Wed Aug 12 13:14:12 1992
  22.  
  23. "Stack has moved into application heap" is an accurate description of
  24. your problem. I recently suffered through a similar problem, so let me
  25. see if I can pass along the useful explanations I got.
  26.  
  27. The stack grows up from low memory, and the heap grows down from high
  28. memory. If the zone size of your application is less than the sum of
  29. the stack and heap sizes, you'll collide as soon as you cause the
  30. stack to grow too much.
  31.  
  32. Deeply nested routines, or lots of local procedure variables, are
  33. frequent culprits.
  34.  
  35. To fix this, make sure that your SIZE resource is correct. For
  36. example, I had a 128k stack and a 640k application heap in a 512k
  37. partition. Boom!
  38.  
  39. Also be careful about static allocation of large structures. Dynamic
  40. allocation _with NewHandle & NewPtr_ is the way to go whenever
  41. possible.
  42.  
  43. Good luck, and hope this helps.
  44.  
  45. -Paul
  46.  
  47. ======================================
  48. From robichau@lambda.msfc.nasa.gov Wed Aug 12 15:02:34 1992
  49.  
  50. Many Toolbox operations return error codes when they interrupt operations
  51. due
  52. to a lack of RAM. QuickDraw, on the other hand, fails spectacularly in some
  53. cases and fails quietly in others.
  54.  
  55. I'm not sure about the File Manager routines. Try increasing the
  56. application
  57. size again (to give your app more memory; remember the guidelines in my
  58. last
  59. message) and keep on truckin'.
  60.  
  61. Regards,
  62. -Paul
  63.  
  64. ======================================
  65. From zben@ni.umd.edu Wed Aug 12 16:34:16 1992
  66.  
  67. Both 28 and 25 make sense if you're just using more memory than
  68. is available in your stack frame.  In one case the stack grows
  69. into the heap, in the other case the heap grows into the stack.
  70. It's the same problem, but you get different error codes
  71. depending on who detects it first.
  72.  
  73. ======================================
  74. From d88-jwa@nada.kth.se Wed Aug 12 17:03:36 1992
  75.  
  76. You're probably zapping memory, like not passing a large
  77. enough buffer, or passing a long count instead of a pointer
  78. to one, or whatever.
  79.  
  80. Turn on "require prototypes" and turn off "simplyfy prototypes"
  81. in Mac#Includes.c and recompile your MacHeaders and then your
  82. project.
  83.  
  84. ======================================
  85. From julen@inf.ethz.ch Thu Aug 13 04:30:08 1992
  86.  
  87. hi!
  88.  
  89. possible reasons include:
  90. 1) recursion somewhere, probably with local variables...
  91. 2) you are not giving back all the memory you allocate. use a global
  92. varibale to keep track of the total ram allocated (ie each time you
  93. allocate you add the size to the var, each time you dispose, you decrement
  94. the var). test the counter just before the crashing fsread, so you can
  95. check it from inside macsbug. it would look something like: (in pascal,
  96. similiar in c)
  97.  
  98. if globalcounter <> 0 then;
  99. fsread (...)
  100.  
  101. and from inside macsbug:
  102.  
  103. TST.L -xxx(A5)
  104. ...
  105. JSR fsread
  106.  
  107. you can then test the counter with
  108. dm a5-xxx
  109.  
  110. hope this helps ;-)
  111.  
  112. --markus
  113.