time@tbomb.ice.com (Tim Endres) (12/06/90)
I have an application which uses the SetGrowZone() trap to install a grow zone procedure. It was bad enough to find out that MultiFinder patched this procedure and returning zero does not cause NewPtr() or NewHandle() to return NULL! Now I have discovered that on IIcx's and SE's running System 6.0.7 the SetGrowZone() returns a nonzero result that does not look like a valid error code!!!!!!!! This appears to be a BUG in SetGrowZone()! On my IIfx and my IIx, SetGrowZone() returns noErr, as it should. On the IIcx it returns a number like $006abcc4. This is not a valid error code, and it appears to be an address to something. MacsBug dm command shows "In RAM but not in the Application or System Heaps". This is a real problem! And I can not imagine it doesn't affect other applications using SetGrowZone(). Am I missing a tech note that states SetGrowZone()'s result has changed? Is this $BCC4 a valid result code?! I have also seen $006ef614, or an error code of $F614. Thanks, tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uunet!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
daven@svc.portal.com (12/07/90)
In article <1CE00001.m31reu@tbomb.ice.com> time@tbomb.ice.com writes: > >I have an application which uses the SetGrowZone() trap to install >a grow zone procedure. > >Now I have discovered that on IIcx's and SE's running System 6.0.7 >the SetGrowZone() returns a nonzero result that does not look like >a valid error code!!!!!!!! > >This appears to be a BUG in SetGrowZone()! > >On my IIfx and my IIx, SetGrowZone() returns noErr, as it should. >On the IIcx it returns a number like $006abcc4. This is not a valid >error code, and it appears to be an address to something. MacsBug >dm command shows "In RAM but not in the Application or System Heaps". > Tim, In C or Pascal, SetGrowZone() is a procedure, not a function. It does not return anything. We've been using SetGrowZone() for years and it has worked just fine for us - but then again we don't test for a return value. -- ------------------------------------------------------------------------------- Dave Newman - Sofware Ventures | daven@svc.portal.com | AppleLink: D0025 Berkeley, CA (415) 644-3232 | AOL: MicroPhone | CIS: 76004,2161 -------------------------------------------------------------------------------
time@tbomb.ice.com (Tim Endres) (12/07/90)
In article <1990Dec6.204708.15592@svc.portal.com>, daven@svc.portal.com writes: > In C or Pascal, SetGrowZone() is a procedure, not a function. It does > not return anything. We've been using SetGrowZone() for years and it > has worked just fine for us - but then again we don't test for a > return value. Thanks, that is the correct answer. I am implementing the trap call in Assembler, and Inside Mac Vol II page 42 clearly states that d0 returns a result code. However, I did not make the logical leap to see that the Pascal call (shown just above the assembler comment :) was a procedure. I starting trapping applications, and all of them ignored the return code. This is when I realized the answer that you gave. Gotta take that bible with a grain of salt some times. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
time@tbomb.ice.com (Tim Endres) (12/08/90)
In article <47202@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) writes: > Hmmm...that's an interesting quesion: Does MemError hold the same > value as D0 after SetGrowZone? If not, then that means that something > happened to D0 between the time SetGrowZone completed and the time > your application regained control. That in turn will indicate if it is > indeed a patch that is munging D0. > -- > In all of the code that I disassembled the value in d0 was immediately stored in MemErr after the trap. However, the fact remains that the trap is returning a non-zero value in d0 on IIcx's. I believe, almost certainly, that it is the MultiFinder patch to SetGrowZone() that is the culprit. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
daven@svc.portal.com (12/08/90)
In article <1CE00001.66qcvx@tbomb.ice.com> time@tbomb.ice.com writes: >I am implementing the trap call in Assembler, and Inside Mac Vol II >page 42 clearly states that d0 returns a result code. However, I did >not make the logical leap to see that the Pascal call (shown just >above the assembler comment :) was a procedure. > >I starting trapping applications, and all of them ignored the return >code. This is when I realized the answer that you gave. Gotta take >that bible with a grain of salt some times. Tim, I kind of suspected you were working in assembler. I noticed the assembler info mentioned D0 holding the error result and it made me wonder. I suspect just about everyone who's been through IM more than once keeps a saltshaker handy. :) -- ------------------------------------------------------------------------------- Dave Newman - Sofware Ventures | daven@svc.portal.com | AppleLink: D0025 Berkeley, CA (415) 644-3232 | AOL: MicroPhone | CIS: 76004,2161 -------------------------------------------------------------------------------
keith@Apple.COM (Keith Rollin) (12/08/90)
In article <1CE00001.66qcvx@tbomb.ice.com> time@tbomb.ice.com writes: > >In article <1990Dec6.204708.15592@svc.portal.com>, daven@svc.portal.com writes: >> In C or Pascal, SetGrowZone() is a procedure, not a function. It does >> not return anything. We've been using SetGrowZone() for years and it >> has worked just fine for us - but then again we don't test for a >> return value. > >Thanks, that is the correct answer. > >I am implementing the trap call in Assembler, and Inside Mac Vol II >page 42 clearly states that d0 returns a result code. However, I did >not make the logical leap to see that the Pascal call (shown just >above the assembler comment :) was a procedure. > >I starting trapping applications, and all of them ignored the return >code. This is when I realized the answer that you gave. Gotta take >that bible with a grain of salt some times. I actually think that there is still something a little goofy going on. Almost ALL Memory Manager and OS routines return a result in D0. I think that the only excections for the Memory Manager are SetHandleSize and SetPtrSize. However, this result is never returned directly to the application. Instead, you are supposed to query MemError for the result code. It is D0 that gets stuffed into MemError. However, I don't think that anyone really expects SetGrowZone to return an error (IM says that the only result code is noErr), and so never check, which is why no one else is running into the problem you are. Hmmm...that's an interesting quesion: Does MemError hold the same value as D0 after SetGrowZone? If not, then that means that something happened to D0 between the time SetGrowZone completed and the time your application regained control. That in turn will indicate if it is indeed a patch that is munging D0. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions