>
> >> But, even after setting all the metric values and bitmap, it is not
> >> displaying a glyph in `ftview' and just displaying a blank output.
>
> Thanks to your new branch in `freetype2-demos' I can finally test the
> GF+TFM combo...
>
> Assuming that you are running a GNU/Linux box: Have you ever used
> `valgrind', as I've recommended to you a few times?
>
Yes I have :-), Also if you see the `cleaned' branch and debug it with
`valgrind'
you will find it completely error free. These errors by `valgrind' are
reported
after I changed the logic to load bitmaps on demand, and as reported by you
because of the double free in `tfm module'. Sorry for that, I'll fix it :-)
FT2_DEBUG=any:7 valgrind ./ftview 20 cmr10.600gf &> cmr10.600gf.log
>
> Doing this you can immediately see in `cmr10.600gf.log' that there is
> a double free:
>
> ...
> TFM_Read_Metrics: TFM Metric Information:
> Check Sum : 1274110073
> Design Size: 10
> Begin Char : 0
> End Char : 127
> font_bbx_w : 10
> font_bbx_h : 10
> slant : 0
> Invalid read of size 8
> at 0x412F6D: FT_Stream_Free (ftobjs.c:251)
> by 0x41718E: FT_Attach_Stream (ftobjs.c:2711)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
> Address 0x79a80c8 is 56 bytes inside a block of size 80 free'd
> at 0x4C2B35C: free (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DF876: ft_free (ftsystem.c:138)
> by 0x42256C: ft_mem_free (ftutil.c:174)
> by 0x4DDE84: tfm_close (tfmobjs.c:136)
> by 0x47F8F1: TFM_Read_Metrics (gfdrivr.c:511)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> Block was alloc'd at
> at 0x4C2A110: malloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DF82B: ft_alloc (ftsystem.c:76)
> by 0x42229F: ft_mem_qalloc (ftutil.c:76)
> by 0x422220: ft_mem_alloc (ftutil.c:55)
> by 0x412E2C: FT_Stream_New (ftobjs.c:197)
> by 0x41710B: FT_Attach_Stream (ftobjs.c:2698)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>
> `FT_Attach_Stream' frees the stream passed as an argument to
> `TFM_Read_Metrics' by itself. While you have modeled your code after
> `afm_parser_init', you've missed that this function allocates a new
> stream but your code doesn't. This means that in `tfm_close' you must
> not close the stream since this happens later on.
> Applying this fix
>
> diff --git a/src/tfm/tfmobjs.c b/src/tfm/tfmobjs.c
> index 8cd3b5bf5..c03873e7a 100644
> --- a/src/tfm/tfmobjs.c
> +++ b/src/tfm/tfmobjs.c
> @@ -131,9 +131,10 @@
> FT_LOCAL( void )
> tfm_close( TFM_Parser parser )
> {
> - FT_Memory memory = parser->memory;
> + FT_UNUSED( parser );
>
> - FT_FREE( parser->stream );
> +
> + /* nothing */
> }
>
> helps.
>
Done!
>
> Note that there are still memory leaks in your driver.
>
> FT2_DEBUG=any:7 \
> valgrind --leak-check=full \
> --show-leak-kinds=all \
> ./ftview 20 cmr10.600gf
>
> 80 bytes in 1 blocks are definitely lost in loss record 42 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE498: tfm_parse_metrics (tfmobjs.c:282)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 128 bytes in 1 blocks are definitely lost in loss record 44 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE480: tfm_parse_metrics (tfmobjs.c:281)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 288 bytes in 1 blocks are definitely lost in loss record 52 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE468: tfm_parse_metrics (tfmobjs.c:280)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 1,024 bytes in 1 blocks are indirectly lost in loss record 58 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE695: tfm_parse_metrics (tfmobjs.c:306)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 1,024 bytes in 1 blocks are indirectly lost in loss record 59 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE6B4: tfm_parse_metrics (tfmobjs.c:307)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 1,024 bytes in 1 blocks are indirectly lost in loss record 60 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE6D3: tfm_parse_metrics (tfmobjs.c:308)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 1,024 bytes in 1 blocks are definitely lost in loss record 61 of 73
> at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DE450: tfm_parse_metrics (tfmobjs.c:279)
> by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
> by 0x406FC4: event_font_change (ftview.c:1039)
> by 0x408C10: main (ftview.c:1904)
>
> 3,176 (104 direct, 3,072 indirect) bytes in 1 blocks are definitely lost
> in loss record 68 of 73
> at 0x4C2A110: malloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> by 0x4DF7F9: ft_alloc (ftsystem.c:76)
> by 0x42229F: ft_mem_qalloc (ftutil.c:76)
> by 0x422220: ft_mem_alloc (ftutil.c:55)
> by 0x47F7AE: TFM_Read_Metrics (gfdrivr.c:478)
> by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
> by 0x417089: FT_Attach_File (ftobjs.c:2672)
> by 0x40A756: my_face_requester (ftcommon.c:267)
> by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
> by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
> by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
> by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>
> >> I tried finding the error but could not locate it, can you please
> >> help me what am I missing.
>
> Regarding locating an error: All FreeType error and tracing messages,
> together with valgrind messages (or clang errors and warnings if you
> compile with sanitizer flags) are sent to `stderr'. Your inserted
>
> printf("Hi I reached here\n");
>
> message, however, goes to `stdout'. These two streams are not always
> synchronized since `stdout' is buffered normally while `stderr' is not
> – this is basic C language knowledge. In other words, it can happen
> that you see your message much later than other tracing or error
> messages. If you insert such debugging aids, you should always send
> data to stderr:
>
> fprintf(stderr, "Hi I reached here\n");
>
Uh, Oh That was put for some other reason I forgot to remove it. Also my
doubt
was that now as the `gf' driver is loading bitmaps on demand, and even
after
allocating bitmaps and metrics correctly(as I compared the debugging
output of
the `cleaned' and `wip' branches ), it is not loading glyphs.
However, now I'll solve the memory errors first and then check.
If you can point to some possible source of error, please let me know.
Thank you
Parth
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
