freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] Memory problem when freeing cache nodes...


From: David Turner
Subject: Re: [Devel] Memory problem when freeing cache nodes...
Date: Sat, 17 Jul 2004 19:32:15 +0200
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

Hello Stephen,

Stephen Perry wrote:
Hi, me again :-)

In my previous email I mentioned a problem with FTC_Manager_FlushN() and suggested a potential fix. I've been running with it for a while now and haven't received any better suggestions but it seems to be working OK.

I've just comitted a simpler fix to the problem. However, yours is perfectly
OK in terms of correctness.

With the fix in place I'm now hitting another problem far more frequently (this problem was also present before my change to FTC_Manager_FlushN()). The problem is that my face requester callback is called with a face ID that has already been freed (in my case it's 0x69696969). This appears to happen because the call to ftc_snode_load() from FTC_SNode_New() has failed resulting in a call to FTC_SNode_Free(). This results in a call to FTC_GNode_UnselectFamily() which if the reference count becomes zero frees the family node. Unfortunately the freed family node is still referenced from the FTC_GQuery passed to FTC_SNode_New() and this appears to ultimately get passed through to the face requester callback.

Unlike with the previous problem I don't really know what the correct solution is here. FWIW both of theses problems are present in 2.1.8 and current unstable code as well. Does anyone have a better of what shoud be happening?

I've also commited the correct solution: the family object was deleted when
ftc_snode_load failed because its reference count (i.e. "num_nodes" field
was still 0). The solution it to increment the field before the lookup
call, then decrement it just after.

The fix is simple and doesn't seem to affect performance at all, which is
hopeful since this is the very performance-critical part of the cache
sub-system. By the way, You'll need to re-compile your code if you use
any of the internal cache headers to define your own cache types,
the macro FTC_GCACHE_LOOKUP has changed to incdlue the fix as well.

Thanks a lot for spotting these problems. I've also taken a quick look at
the rest of the code, and couldn't find any other location with a reference
count of 0 being used anywhere.

Best Regards,

- David Turner
- The FreeType Project  (www.freetype.org)



Many thanks,


steve.


******************Legal Disclaimer**************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email address@hidden, and delete the message. Thank you."
************************************************************


_______________________________________________
Devel mailing list
address@hidden
http://www.freetype.org/mailman/listinfo/devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]