#134 Make example graph_display.cpp function

For next release
open
nobody
None
5
2013-06-23
2013-06-22
Adam Miller
No

This request seeks to make it known that when compiling the example graph_display with qt5, it crashes due to an uninitialized pointer, line 49 in FTSize.cpp under thirdparty/ftgl/FTSize.cpp. The pointer causing the crash is the parameter given to the function, FT_Face *face, originating from FTFace::Size's not having initialized its member variable ftFace when passing it to charSize.CharSize.

Because I'm not actually familiar with the source of the libraries themselves and how they tie together, I can't say I can suggest the best proper fix here, because I don't know where a FT_Face object should be initialized, in terms of organization, and the way I see it, I would be adding code to something that a number of other objects depend on.

Discussion

  • Adam Miller
    Adam Miller
    2013-06-22

    Actually, After looking at it more and reviewing the stack trace, I feel much more confident that the fix is simply a "ftFace = new FT_Face;" that should be performed at some level within the GlLabel::init function call but also before descending into the third party packages, like ftgl. I'm pretty sure that third party packages should remain unchanged. Whether or not the change should be made within the init function itself, or if it belongs to the FTPolygonFont constructor (or some inner class or parent of it) is something that requires a little more familiarity with this code.

    Here's my stack trace, since I didn't give it the first time:

    pastebin.com/mzeb96PQ

     
  • Adam Miller
    Adam Miller
    2013-06-23

    So, after looking at it futher, I realize that the change cannot be a simple ftFace = new FT_Face placed outside of the third party packages for the reason that in FTSize.h the FT_Face *ftFace object is marked private in FTSize. This requires either marking that member public or editing code of the ftgl in order to make sure that it gets initialized before being dereferenced, or to put a safety check in place so that the dereference does not occur... I'm not sure what the proper course of action is because it affects a lot of people, and because Tulip is built around this. It may be better to create the sample from scratch by looking at the construction of the existing tulip and seeing what function calls are made.