ews00461@uxa.cso.uiuc.edu (03/03/90)
I'm having great memory management problems, again: Using LSC 3.0, my appl mf partition is 512 k, I call maxapplzone, and call moremasters 50 times. I'm using Transkel and TransEdit. All memory allocated by my program is in relocatable handles, lots of them and they are mostly small. At seemingly random times, the largest available block, according to MaxMem and MaxBlock, takes a big dive. At one point in the program... 3196 handles ever allocated 166053 bytes in handles ever allocated 2117 handles ever dropped 109444 bytes in handles ever dropped 1079 net handles left allocated 56609 net bytes in handles allocated 304034 total free bytes 292178 biggest chunk, MaxMem The program is essentially working like an MPW worksheet. It waits for input, processes it, and waits for more, etc... At this point, I type 'sysmem' again, which is the command that produces the above statistics... 3198 handles ever allocated 166097 bytes in handles ever allocated 2119 handles ever dropped 109488 bytes in handles ever dropped 1079 net handles left allocated 56609 net bytes in handles allocated 303738 total free bytes 36868 biggest chunk, MaxMem The program has requested 2 blocks of 22 bytes each and disposed of both of them. Why has MaxMem taken such a dive ? Note that the total handles allocated statistics are maintained on the fly by my own memory management routines. For example, I have a routine called GetHandle(Size s), which adds s to the total allocated and returns NewHandle(s), no big deal. I know of no routines in my code or TransSkel which call newhandle or newptr without using my interfaces. I've tried calling moremasters more and less times. Maxapplzone is being called twice, once by my program and once by transkel after the 50 calls to moremasters. I've tried deleting my call to maxapplzone, no effect. The 255 k drop illustrated above is a bad example, but nearly every pass through my interpreter loop, 3-4 k is getting devoured. Best I can tell, the drop in the largest size does not occur in conjunction with my code, because the problem generally occurs near the screen update. I am buffering all output and TEInserting it all at once. Sade Heap, indicates several free blocks at the end of the zone, one of which is 200+ k, but they are distinct blocks. Why didn't MaxMem coalesce them ? I recently redesigned my data structures and I am aware that the program now requests many more handles of a smaller size than it did before. This problem was not occuring in the old structure. If I allow the interpreter to continue getting its memory stolen, eventually it sort of locks up. The mouse will move, the watch is on, but it does not return. Pressing the sadekey and examining the heap shows a bad heap (one with an invalid block length). The program has 6 segments, including the jump table. The same problem occurs with different mf partition sizes. Any ideas ? Thanks in advance, Eric W Sink University of Illinois ews00461@uxa.cso.uiuc.edu
ews00461@uxa.cso.uiuc.edu (03/06/90)
In response to my own note... Two wise persons have mailed me to tell me of the problems with TextEdit and the growing textedit records/linestarts array. Sure enough, the handlesize of the textedit record in question is growing 16 bytes for every insertion of 8 lines, as expected by a corresponding change in the linestarts array. So, I speculate that the cause of the program locking up is: When TransEdit calls TECalText, it attempts to SetHandleSize(), cannot find the necessary memory and hangs (or my program does not check some error condition and it is my fault it hangs). I am not intimately familiar with SetHandleSize(), but it seems that I may be able to place the TextRec in high memory or something like that to avoid this problem... Any further comments/suggestions ? Thanks very much! Eric W Sink University of Illinois ews00461@uxa.cso.uiuc.edu