bugThe FreeType Project - Bugs: bug #27648, No way to initialize 'raster'...


You are not allowed to post comments on this tracker with your current authentication level.

bug #27648: No way to initialize 'raster' field for custom renderers => segfault in FT_Done_FreeType

Submitted by:  None
Submitted on:  Fri 09 Oct 2009 02:56:37 PM UTC  
Severity:  3 - Normal Item Group:  Crash
Status:  Fixed Privacy:  Public
Assigned to:  Werner LEMBERG <wl> Open/Closed:  Closed
Planned Release:  2.3.13

Mon 05 Jul 2010 08:39:07 PM UTC, comment #2: 

Patch applied, thanks.  Sorry for the long delay.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 13 Oct 2009 06:56:34 AM UTC, comment #1: 

As a workaround for the problem, one can check glyph format before trying to release the raster - see the patch attached.

As far as I can see, allocation of raster is already done this way.

(file #18869)

Eugene A. Shatokhin <euspectre>
Fri 09 Oct 2009 02:56:37 PM UTC, original submission:  

There is no way to properly initialize 'raster' field of the custom renderers for glyph formats except FT_GLYPH_FORMAT_OUTLINE.

If this field is not initialized at least with NULL, it may lead to memory access violation when trying to release the library. FT_Done_Freetype eventually calls ft_remove_renderer(). Consider the following lines of this function (ftobjs.c from git repository, line 3682):

      /* release raster object, if any */
      if ( render->raster )
        render->clazz->raster_class->raster_done( render->raster );

As far as I can see from Freetype reference, 'raster_class' is intended to use for FT_GLYPH_FORMAT_OUTLINE renderers only. As for the renderers for other formats, this field should probably be set to NULL.

So, as render->raster is not initialized and may contain some non-NULL garbage, the lines above will result in NULL pointer dereference. Even if 'render->clazz->raster_class' is not NULL and provides 'raster_done' method, the latter will be called with an invalid pointer - access violation again.

The definition of FT_RendererRec_ structure is private and hence 'raster' field is not accessible directly (and it probably should not be).

Initialization of render->raster via raster_new() is available only for FT_GLYPH_FORMAT_OUTLINE format, so this too cannot be used as a workaround.

If 'raster' field was automatically set to NULL somehow when a non-FT_GLYPH_FORMAT_OUTLINE renderer is created, it would solve the problem. Or maybe there are other solutions.

[NB] It should also be mentioned that the description of FT_Renderer_Class_ states that the structure must also contain 'raster' field. The structure itself however has in fact all the described fields except for 'raster' (ftrender.h).

Probably the structure should not contain this field at all and it got into the description by mistake. After all, as far as I can see, only 'raster' field of FT_Renderer_Rec_ is used by Freetype library, rather than that field of FT_Renderer_Class_ structures.

Not sure if the issues described above are related.



Attached Files
file #18869:  raster.patch added by euspectre (742B - application/octet-stream - A patch that may fix the problem.)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by euspectre (Updated the item)
  • -email is unavailable- added by euspectre (Perhaps there was a problem with cookies in my browser when I was submitting this bug report. As a result the submitter is "Anonymous".)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-05 wl StatusNone => Fixed
        Assigned toNone => wl
        Open/ClosedOpen => Closed
        Planned ReleaseNone => 2.3.13
    2009-10-13 euspectre Attached File- => Added raster.patch, #18869
    2009-10-13 euspectre Carbon-Copy- => Added euspectre

    Back to the top

    Powered by Savane 3.7