GG.DAR@forsythe.stanford.edu (Aaron Reizes) (10/16/89)
Unexpectedly Quit Problem, I have an application (MPW C3.0) that allocates most of its structures using non-relocatable pointers (NewPtr). If the user opens lots of windows so that there is not much memory left, and then selects an option that loads a large code segment, my application unexpectedly quits. The only solution I have found is to leave enough memory for a 32kb code segment to load. I do this by checking MaxBlock each time I allocate a new pointer. Have others found this problem, and what is considered the proper procedure to prevent it, or correct it. Thanks in advance. Aaron Reizes reizes@forsythe.standford.edu
tim@hoptoad.uucp (Tim Maroney) (10/16/89)
In article <5174@lindy.Stanford.EDU> GG.DAR@forsythe.stanford.edu (Aaron Reizes) writes: >I have an application (MPW C3.0) that allocates most of its >structures using non-relocatable pointers (NewPtr). If the user >opens lots of windows so that there is not much memory left, and >then selects an option that loads a large code segment, my >application unexpectedly quits. > >Have others found this problem, and what is considered the proper >procedure to prevent it, or correct it. The proper procedure, not to be too flip, is to use NewHandle instead of NewPtr. If you use NewPtr's and your code is such that memory can fill up under normal conditions, then you're asking for this kind of problem. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "This signature is not to be quoted." -- Erland Sommarskog
keith@Apple.COM (Keith Rollin) (10/16/89)
In article <5174@lindy.Stanford.EDU> GG.DAR@forsythe.stanford.edu (Aaron Reizes) writes: >Unexpectedly Quit Problem, > >I have an application (MPW C3.0) that allocates most of its >structures using non-relocatable pointers (NewPtr). If the user >opens lots of windows so that there is not much memory left, and >then selects an option that loads a large code segment, my >application unexpectedly quits. > >The only solution I have found is to leave enough memory for a 32kb >code segment to load. I do this by checking MaxBlock each time I >allocate a new pointer. > >Have others found this problem, and what is considered the proper >procedure to prevent it, or correct it. > MacApp goes through great pains to make sure that this never happens to you. Assuming that you set things up right, it makes sure that your program will NEVER fail because it could not load in a System or CODE resource. It does this with a two forked technique. First of all, it determines how much memory your program will ever need to hold all System and CODE resources at the time or maximum use. It goes and totes up the sizes of all the CDEF, WDEF, LDEF, PACK, and MDEF resources, adds to that the sizes of the CODE resources that you can specify, and then even adds in a little slop for good measure. It then makes sure that there is always enough memory to hold all of these. It does this by taking the total size of memory needed, and subtracting the memory already in use by these resources. Taking the difference, it allocates a holding buffer. The second part of the technique takes place in MacApp's GrowZoneProc. This procedure is responsible for the maintenance of the space holder. If space is needed for your CODE resource or other System resource listed above, then the size of the space holder is decreased to allow that resource to be loaded. This is just the genereal idea of how MacApp handles this problem, and I've skipped over a lot of the details. It should also be obvious that there is a lot of work involved in implementing this scheme. However, it is one of the most robust techniques that I know of, and is one of the better reasons for using MacApp in developing programs. If you are interested, I could send you some more information on the technique and implementation. Or, if it is available to you, look at the file called UMemory.p that comes with MacApp; the comments there are very complete in describing what is going on. -- ------------------------------------------------------------------------------ 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
lsr@Apple.COM (Larry Rosenstein) (10/16/89)
In article <35672@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > It does this with a two forked technique. First of all, it determines how much > memory your program will ever need to hold all System and CODE resources at the > time or maximum use. It goes and totes up the sizes of all the CDEF, WDEF, Actually, you have to configure this number in a resource. MacApp does provide tools to help determine the maximum code usage of the program. Assuming that you tell MacApp the maximum, then it will ensure that the maximum is always available. The technique of ensuring that a 32K block is always available will work, provided any particular operation requires that only one extra code segment be loaded. Otherwise, you might have enough to load 1 segment but not the second. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1