Re: [ft-devel] More crashes on ARM

[david turner]

Frank Meerkoetter a écrit :
> Quoting david turner <address@hidden>:
>
> Hello,
>
> > the "cmap->clazz" value is definitely wrong, and there is no way the
> > charmap was built
> > with it. In other words, the field has been rewritten after creation of
> > the charmap !!
> >
> > Can you re-run the program but set a watch on the fields's memory
> > address ? This would
> > help us spot the problem.
>
>
> FT_CMAP is than used to cast a part of the FT_Face structure
> into a FT_CMAP structure (1).
nope, the cast is correct, because the FT_CharMap type is a _pointer_ to a
FT_CharMapRec structure, likewise an FT_CMap is a pointer to a FT_CMapRec
structure, which itself is declared with something like:

 typedef struct FT_CMapRec_
 {
    FT_CharMapRec   cmap;
    FT_CMap_Class    clazz;

 } FT_CMapRec, *FT_CMap;

think about FT_CharMapRec as an abstract "object class", and FT_CMapRec 
as a derived
"class". Clients of the library don't need to know the details of a 
FT_CMapRec, they'll
only be able to read the root fields from the FT_CharMapRec.

By the way, the FT_CMap objects are created in src/base/ftobjs.c 
(FT_CMap_New).

Can you put a watchpoint on the cmap's "clazz" field to detect where it 
is over-written ?
Really, it should give us meaningful information.

Regards,

- David

> FT_Get_Next_Char( FT_Face   face,
>                     FT_ULong  charcode,
>                     FT_UInt  *agindex )
>   {
>     FT_ULong  result = 0;
>     FT_UInt   gindex = 0;
>
>
>     if ( face && face->charmap )
>     {
>       FT_UInt32  code = (FT_UInt32)charcode;
>       FT_CMap    cmap = FT_CMAP( face->charmap );  // (1)
>
>
>       gindex = cmap->clazz->char_next( cmap, &code );
>       result = ( gindex == 0 ) ? 0 : code;
>     }
>
>     if ( agindex )
>       *agindex = gindex;
>
>     return result;
>   }
>
> (gdb) p *cmap
> $32 = {charmap = {face = 0x4bb90, encoding = FT_ENCODING_UNICODE,
>     platform_id = 0, encoding_id = 3}, clazz = 0x30000}
>
> My guess is that clazz should point to 0x505b8 (aka. driver).
> Is this correct?
>
> Regards,
>   Frank

***********************************************************************************
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 
message.
***********************************************************************************