drew@cat45.CS.WISC.EDU (Shawn Drew) (02/21/89)
Here's a simple question for you. What are the general rules of when to dispose a ptr/handle and when not to (assuming I'm finished with it). Sometimes I would dispose of a ptr/handle that I thought I was through with and then crash. Thanks for the info. ****** The opinions expressed in this article are my own ****** ********** Who else would want to claim them? *********** drew@cat45.cs.wisc.edu
bob@accuvax.nwu.edu (Bob Hablutzel) (02/21/89)
> Here's a simple question for you. What are the general rules of when to > dispose a ptr/handle and when not to (assuming I'm finished with it). > Sometimes I would dispose of a ptr/handle that I thought I was through with > and then crash. > Thanks for the info. I'd be willing to bet that if you think you are done with a handle, you are done with a handle (or pointer). But remember - having disposed of a handle/ pointer subjects the heap to a shake-up. Make sure that any handles you are still using are properly locked if derefed, and deref them again if not. The only exception I know if are system resources, which you don't dispose. Bob Hablutzel Wildwood Software BOB@NUACC.ACNS.NWU.EDU
jackiw@cs.swarthmore.edu (Nick Jackiw) (02/22/89)
In article <7208@spool.cs.wisc.edu> drew@cat45.CS.WISC.EDU (Shawn Drew) writes: > Here's a simple question for you. What are the general rules of when to > dispose a ptr/handle and when not to (assuming I'm finished with it). > Sometimes I would dispose of a ptr/handle that I thought I was through with > and then crash. > > drew@cat45.cs.wisc.edu The general rule is simple: throw it away as soon as you're guaranteed never to need the data it holds again. The complications are anything BUT simple. Your crashes are the result of either someone (presumably NOT you) wanting data from the block you've already disposed, or YOU disposing of the block after someone else has already done that (double-disposes frequently crash). Faithful attention to InsideMac is the only way to know who wants what with your data and who's going to dispose it when. Some of the most common errors involve DisposeWindow and DisposeDialog, which dispose all sorts of other things (any controls in them, their resources, etc.); and the Resource Manager, which changes its idea of who owns what and whether it should clobber them just for fun as often as the wind... (:-) Good debugging...a discipline (i. e. with techniques) instead of a final bout of wishful hacking...is also necessary. If you're crashing and have reason to believe it's memory management related, first get a REPRODUCIBLE version of the crash. Then, reinvoking that crash consistently, use breakpoints to locate where it happens. Once you've found the offending line, if the bug isn't staring you in the face, you have to begin reverse-engineering the process that resulted in this line. If this means deleting all of your DisposeXXX() toolbox calls, and replacing them one by one til you find the one that's bad, so be it. "No silver bullet," the adage goes. -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ By the time my employer decides on its opinion, I'll be dead.
rdsesq@Jessica.stanford.edu (Rob Snevely) (02/22/89)
Hello, I hope that someone out there can help me. I seem to be having a problem In short: I call SetWindowPic to put a pict in to a window, this stores the picHandle in the window record. When I call disposeWindow, It disposes the window but does not dispose the picHandle. I can use disposHandle, but I can't figure out where SetWindowPic is putting the handle in the window record. And inside Mac does'nt want to tell me where SetWindowPic is putting the picHandle in the window record. This is all from inside mac Vol 1. Any ideas or does someone know where I can find a solution. I would think that disposeWindow should get rid of it, but according to inside Mac if you are reading the picture from a resource, it does not. Please e-mail me or post if you think it would be of general interest. Thanx in advance, Hope to hear from somebody. rob snevely rdsesq@jessica.stanford.edu
cyosta@taux01.UUCP ( Yossie Silverman ) (02/22/89)
There is a question that has been bugging me since I started programming the mac. I have never been bitten so I never bothered to find out the truth before. The question is: When I do a _NewHandle or _NewPtr, is the result (1) locked (2) unpurgable ? Further, the various size change routines, do they modify either of these attributes? My general stratagy is to do _NewHandle's and _Lock just before a 'with' statement and _UnLock just after it. I assume that the handle is unpurgable, so far it has worked. The book says very little about the defaults, infact, the promotion IM says NOTHING about the defaults... -- Yossie Silverman What did the Caspian sea? National Semiconductor Ltd. (Israel) - Saki UUCP: cyosta%taux01@nsc.COM NSA LSD FBI KGB PCP CIA MOSAD NUCLEAR MI5 SPY ASSASSINATE SDI -- OOCLAY ITAY
pratt@boulder.Colorado.EDU (Jonathan Pratt) (02/23/89)
In article <1152@taux01.UUCP> cyosta%taux01@nsc.COM ( Yossie Silverman ) writes: >truth before. The question is: When I do a _NewHandle or _NewPtr, is >the result (1) locked (2) unpurgable ? Further, the various size change ... >worked. The book says very little about the defaults, infact, the promotion >IM says NOTHING about the defaults... ??????? Odd, but on page 32 of the Memory Manager chapter of my promotional IM it says (about NewHandle()): The new block will be unlocked and unpurgeable. In fact, the sentence erroneously appears twice. As for pointers, their blocks are, by definition, immobile (and unpurgeable). Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */
brecher@well.UUCP (Steve Brecher) (02/23/89)
In article <10050077@accuvax.nwu.edu>, bob@accuvax.nwu.edu (Bob Hablutzel) writes: > [H]aving disposed of a handle/ pointer subjects the heap to a shake-up. Make > sure that any handles you are still using are properly locked if derefed, and > deref them again if not. Disposing a heap block does not relocate any other blocks. -- brecher@well.UUCP (Steve Brecher)
anson@spray.CalComp.COM (Ed Anson) (02/23/89)
In article <1152@taux01.UUCP> cyosta%taux01@nsc.COM ( Yossie Silverman ) writes: > The question is: When I do a _NewHandle or _NewPtr, is >the result (1) locked (2) unpurgable ? About NewHandle, Inside Macintosh II-32 says: "The new block will be unlocked and unpurgeable." > The book says very little about the defaults, infact, the promotion >IM says NOTHING about the defaults... That's why you should use the current documentation. The promotion edition is incomplete, and has even more errors than the final version. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
news@Portia.Stanford.EDU (USENET News System) (02/24/89)
From: rdsesq@Jessica.stanford.edu (Rob Snevely) Path: Jessica!rdsesq rob
rdsesq@Jessica.stanford.edu (Rob Snevely) (02/24/89)
It seems to have ate my 1st message. So I'll send it again. Many thanx to all who reponded to my question. rob
ech@pegasus.ATT.COM (Edward C Horvath) (02/24/89)
In article <1152@taux01.UUCP> cyosta%taux01@nsc.COM ( Yossie Silverman ) writes: >...IM says NOTHING about the defaults... From article <6850@boulder.Colorado.EDU>, by pratt@boulder.Colorado.EDU (Jonathan Pratt): >...In fact, the sentence erroneously appears twice... Obviously Jonathan's manual got the copy of the sentence intended for Yossie's. Which makes me wonder: the Reality Manager appears twice in my copy of IM-5. Is somebody out there missing theirs? =Ned Horvath= Oh, yes: :-)
rick@Jessica.stanford.edu (Rick Wong) (02/24/89)
In article <10814@well.UUCP> brecher@well.UUCP (Steve Brecher) writes: > . . . >Disposing a heap block does not relocate any other blocks. > Appendix B of IM vol. III lists DisposHandle and DisposPtr among the routines that may move or purge memory. Even if the routines currently don't cause a heap scramble, it's safer to take Inside Macintosh at its word. Rick "No, it's Hair Pie" Wong rick@jessica.stanford.edu