ccplumb@rose.uwaterloo.ca (Colin Plumb) (03/21/91)
I'm trying to change some text-rendering code to use the system libraries instead of blitting pieces of a private bitmap. So I made a TextFont structure wrapper, set it to point to the bitmap, made a tf_CharLoc array, etc. Then I did SetFont(rp, &Myfont) and used Text(), and lo! it works. However, my code was eating 24 bytes of fast memory per run and I was going crazy trying to find it. Eventually I single-stepped through with a memory watcher and found that the SetFont() call was allocating 24 bytes of fast memory, and following it with things like SetFont(rp, NULL); or SetFont(rp, old_value_of_rp_Font); did not subsequently free this memory. Neither did closing the old font, or anything else I've been able to think of. Now, my private TextFont structure contains a dummy tf_Message, which I initialise to all zeros. (I've also tried initialising it to all bogus values like 0xDEADBEEF, but it doesn't change anything.) SetFont() sets the mn_ReplyPort to something. It has no name, its ln_Pred points to MyFont, and the initial value I stuff in mn_ReplyPort gets copied to it at an offset of 8, stomping on the ln_Type, ln_Pri and half of ln_Name. Its successor node is full of zeros. (BTW, sizeof(struct MsgPort) = 34. I'm losing 24.) I haven't the faintest f%$^%^ing idea what this is doing (the includes say "reply port for font removal", and I can't find anything further), but would like it to go away. Someone suggested I live with 24 bytes of leakage per run. I'm vaguely dissatisfied with this solution. Can anyone tell me what is going on and what is the right way to create a private TextFont structure? -- -Colin
ccplumb@rose.uwaterloo.ca (Colin Plumb) (03/21/91)
Well, a bit of poking around in the 2.0 includes discovered the answer. It's not a message port; it's just that 2.0 usurped the pointer to point to a TextFontExtension struct. The includes I have say it's a 20 byte struct, but I'm losing 24... it might have been extended since I saw it, or those mysterious GfxFree/GfxNew/GfxAssociate functions I saw doing some bookkeeping for me, but in any case I don't know how to free it safely. More digging, and aha! There are ExtendFont and StripFont functions that look significant... So now my cleanup code, after doing a SetFont() back to the old, saved rp->Font pointer for paranoia's sake, tests to see if the tf_Extension (a.k.a. tf_Message.mn_ReplyPort) pointer holds non-NULL, and if so, calls the 2.0-specific StripFont() function on my TextFont structure. This seems to work, without memory leakage, on both 1.3 and 2.0. So, I think I've found an (admittedly minor) backward-compatibility bug between 2.0 and 1.3. Perhaps some 2.0-knowledgeable (or at least, autodoc-posessing!) person could tell me if this ad hoc solution is indeed correct? The 1.3 manual mentions the importance of putting the old font back into the rastport before closing it, so well-behaved code probably does this already. Perhaps the same logic which automagically called ExtendFont() for me could call StripFont() as part of the cleanup. (The graphics.library seems to need the extension; stuffing the apropriate values into the RastPort structure produces odd effects in JAM2 mode...) Thanks! -- -Colin
ewout@topcat.commodore.com (Ewout Walraven) (03/21/91)
ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: >Well, a bit of poking around in the 2.0 includes discovered the answer. >It's not a message port; it's just that 2.0 usurped the pointer to >point to a TextFontExtension struct. The includes I have say it's >a 20 byte struct, but I'm losing 24... it might have been extended >since I saw it, or those mysterious GfxFree/GfxNew/GfxAssociate functions >I saw doing some bookkeeping for me, but in any case I don't know how to >free it safely. More digging, and aha! There are ExtendFont and >StripFont functions that look significant... >So now my cleanup code, after doing a SetFont() back to the old, saved >rp->Font pointer for paranoia's sake, tests to see if the tf_Extension >(a.k.a. tf_message.mn_ReplyPort) pointer holds non-NULL, and if so, >calls the 2.0-specific StripFont() function on my TextFont structure. >This seems to work, without memory leakage, on both 1.3 and 2.0. >So, I think I've found an (admittedly minor) backward-compatibility bug >between 2.0 and 1.3. Perhaps some 2.0-knowledgeable (or at least, >autodoc-posessing!) person could tell me if this ad hoc solution is >indeed correct? Yes it is. Using SetFont() on in-code TextFonts will loose 24 bytes, unless you call StripFont(). That V36 buglet and how to deal with it are documented in the Autodocs. >Thanks! >-- > -Colin
navas@cory.Berkeley.EDU (David C. Navas) (03/24/91)
In article <1991Mar21.044941.15171@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: >It's not a message port; it's just that 2.0 usurped the pointer to >point to a TextFontExtension struct. The includes I have say it's >a 20 byte struct, but I'm losing 24... it might have been extended Ding! AllocMem, as I'm sure you know, allocates in 8 byte chunks. David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus