Re: [ft-devel] success?

>> 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

From:	Parth Wazurkar
Subject:	Re: [ft-devel] success?
Date:	Fri, 10 Aug 2018 14:12:40 +0530