[Fontconfig] robustness of the mmap cache branch

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

 



On Wed, 2005-09-07 at 11:42 -0400, Patrick Lam wrote:
> Matthias Clasen wrote:
> > I think FcGlobalCacheLoad() needs some robustness love. Just
> > copy any text file to ~/.fonts.cache-2 and watch FcGlobalCacheLoad()
> > go in an infinite loop:
> 
> Actually, FcCacheSkipToArch was looping.  I've fixed this by ensuring
> that FcCacheSkipToArch always makes progress:
> 
> 	if (FcCacheReadString (fd, candidate_arch_machine_name_count,
> 		sizeof (candidate_arch_machine_name_count)) == 0)
>             return -1;
> 	if (!strlen(candidate_arch_machine_name_count))
> 	    return -1;
> 	bs = strtol(candidate_arch_machine_name_count, &candidate_arch, 16);
> 
> +	if (!bs || bs < strlen (candidate_arch_machine_name_count))
> +	    return -1;
> 
> As you suggested, I also check the return values on read and lseek;
> although they weren't the problem in this particular case, it's probably
> still better to fix them.
> 
> Garbage .fonts.cache-2 files no longer trash fontconfig; it now
> correctly regenerates the global cache file.
> 
> pat

I wonder if it would be a good idea to do a development release or
at least create a snapshot tarball off the 2-4 branch, to get some wider
testing, or are there currently any outstanding issues with the mmap
cache that make a test release impractical ?

Matthias



[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux