bugThe FreeType Project - Bugs: bug #48117, Uninitialized error code read in...

 
 

bug #48117: Uninitialized error code read in tt_face_goto_table

Submitted by:  None
Submitted on:  Fri 03 Jun 2016 07:23:34 PM UTC  
 
Severity: 3 - NormalItem Group: Incorrect behaviour
Status: InvalidPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 05 Jun 2016 03:50:24 AM UTC, comment #3:

In FreeType, (almost) all macros are UPPERCASE_ONLY.

It's hard to say without an input file why a given font produces errors or not. Fact is that the library is constantly hardened against invalid or malformed fonts using a fuzzer; if possible, FreeType tries to be very generous if it can sanitize invalid data, but this doesn't always work.

Note that the current version is 2.6.3 (with 2.6.4 to appear within a few weeks).

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sat 04 Jun 2016 11:29:28 PM UTC, comment #2:

Sorry for the noise. My fault. The identifier `FT_STREAM_SEEK` confused my editor. I did not notice it was actually a macro and expand it manually as I should have done for idiomatic C.

Then I found accidentally a malformed font file was in my font path. But why the error 0x90 not triggered in 2.5.x as in 2.4.x?

(file #37389)

Anonymous
Sat 04 Jun 2016 04:39:19 AM UTC, comment #1:

I don't see a bug. If `table` is NULL, `error` is directly set in
the line

error = FT_THROW( Table_Missing );

otherwise, `error` is set in

if ( FT_STREAM_SEEK( table->Offset )

via the `FT_STREAM_SEEK` macro. In other words, all cases are covered.

Please reopen with an example that exhibits the problem if you think that my analysis is flawed.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 03 Jun 2016 07:23:34 PM UTC, original submission:

In file "src/sfnt/ttload.c", the static function 'tt_face_goto_table' uses block scope object 'error' to store the value to be returned, but it is not initialized unless the function fails to find the table. This causes some strange failure randomly.

In fact I met error 0x90 when loading some faces in my program compiled years ago. I found the error disappeared after update to 2.5.0.1 from 2.4.11 (with some workaround not related to this issue, i.e. http://savannah.nongnu.org/bugs/index.php?39383), but nothing in the change log answered the reason. Bisect on the history showed "support for color embedded bitmaps" ("src/sfnt/ttsbit.c") changed the behavior, but that was absurd. So I dug into the source for hours and finally found the bug here in the repo... It was strange that the compiler did not warn against this, in contrast to many other warnings fixed before 2.5 release.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #37389:  en.ttf added by None (135KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by wl (Posted a comment)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 04 Jun 2016 11:29:28 PM UTCNoneAttached File-=>Added en.ttf, #37389
    Sat 04 Jun 2016 04:39:19 AM UTCwlStatusNone=>Invalid
      Assigned toNone=>wl
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1