home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / programm / 22194 < prev    next >
Encoding:
Text File  |  1993-01-26  |  2.3 KB  |  51 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!spool.mu.edu!yale.edu!yale!gumby!kzoo!k044477
  3. From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
  4. Subject: My GrowZoneFunc got a ridiculous request
  5. Message-ID: <1993Jan26.074553.8548@hobbes.kzoo.edu>
  6. Organization: Kalamazoo College
  7. Date: Tue, 26 Jan 1993 07:45:53 GMT
  8. Lines: 41
  9.  
  10. My app went into an infinite loop this afternoon.  When I broke into
  11. Macsbug this evening, I found that it was trying, over and over, to
  12. get enough memory to do a LoadResource().
  13.  
  14. Upon perusal, it turned out that my GrowZoneFunc was being asked to
  15. allocate a bizarre amount of memory.  Namely, 0xDA7DE240 bytes.
  16. That's well over three billion, or about -600,000,000 in signed decimal.
  17. An unusual request.
  18.  
  19.  
  20. It was in the infinite loop because the TCL's grow zone function,
  21. CApplication::GrowMemory(), checks to see whether bytesNeeded minus
  22. freeSpace is less than zero.  That value, of course, was way less than
  23. zero, like about 600 megs less than zero, so it happily returned 1,
  24. telling the Memory Manager "there, I did it--try it now."  The Memory
  25. Manager chokes on the request, re-calls the grow zone function, and
  26. things go on like this for, well, hours.
  27.  
  28. When I forced CApplication::GrowMemory() to return 0, telling the Memory
  29. Manager "sorry, I give up--deny the request", everything worked OK until
  30. that resource was requested again.  Then the GrowZoneFunc was again
  31. called and again asked to free up -600 megs.
  32.  
  33.  
  34. I'm guessing that the resource map is trashed, and that the long that
  35. should read the resource's actual size (about 24K) now reads
  36. "DA7DE240".  That would explain it, I suppose.  But my heap is fine, and
  37. Macsbug correctly tells me the type, ID, and name of every resource in
  38. it.  So it's not _too_ corrupted.  Let's see...well, after refusing that
  39. second request, the game has been working just fine for fifteen
  40. minutes.  And ResEdit verifies the resource file as OK (it's big, 6.4
  41. megs).
  42.  
  43. I figure if I patch GrowMemory() to return 0 if the request if absurd,
  44. that'll take care of the infinite looping.  Should I just call this a
  45. fluke?  Or what?
  46. -- 
  47.  Jamie McCarthy      Internet: k044477@kzoo.edu      AppleLink: j.mccarthy
  48.  "I don't think people need optimization any more. ...  If you look at the
  49.   history of programming-language design, almost every major screw-up is a
  50.   consequence of people pandering to some optimization...."   - S. Wolfram
  51.