> > [commit 11969d558505c338f29b83bbac4d572fb85b3f2b] > > Sorry for the delay in answering your questions; I was abroad without > the ability to update the git repository. > > > I have found that `ftview' is not allocating > > `handle->current_font->num_indices' correctly for the gf driver, > > [...] > > As a rule of thumb: The error is most certainly not in `ftview' but in > your code. It is *very* unlikely that `ftview' works for all formats > but GF... >
I did not mean that the error was in ftview, but I wanted to know where the driver was failing to allocate proper values in ftview. > Attached you can find small fixes to make output of the first `make' > call prettier, and to allow `make devel; make' actually work. I've > also attached the log output of `make devel'; as you can see there are > zillions of warnings that you still have to take care of – if I > remember correctly, I advised you to use `make devel; make' for > development, and it is not clear to me why you didn't follow this > advice... Yes, I was working on it, as I did `make devel; make', but could not figure out why this was not working, I thought first I give a try to learn it and then ask for doubts. Also, I am not well acquainted with valgrind, so I was learning it first and then I was going to reply you. At least you should have analyzed what it does and transfer > the used compiler flags to your build environment. > My bad, really sorry for this, I was in the zeal of moving ahead and as the program was compiling and I ignored those flags. I will fix those asap. Thanks. > After fixing those buglets I compiled the demo programs, and the call > > ftview 20 cmr10.2602gf > > crashed immediately. Running with valgrind gives > > Conditional jump or move depends on uninitialised value(s) > at 0x47D79D: gf_free_font (gflib.c:466) > by 0x47D962: GF_Face_Done (gfdrivr.c:145) > by 0x414CA0: open_face (ftobjs.c:1404) > by 0x416971: ft_open_face_internal (ftobjs.c:2447) > by 0x414D53: FT_New_Face (ftobjs.c:1438) > by 0x40AB1B: FTDemo_Install_Font (ftcommon.c:396) > by 0x408B7C: main (ftview.c:1887) > > Use of uninitialised value of size 8 > at 0x47D7A3: gf_free_font (gflib.c:468) > by 0x47D962: GF_Face_Done (gfdrivr.c:145) > by 0x414CA0: open_face (ftobjs.c:1404) > by 0x416971: ft_open_face_internal (ftobjs.c:2447) > by 0x414D53: FT_New_Face (ftobjs.c:1438) > by 0x40AB1B: FTDemo_Install_Font (ftcommon.c:396) > by 0x408B7C: main (ftview.c:1887) > > Invalid read of size 8 > at 0x47D7A3: gf_free_font (gflib.c:468) > by 0x47D962: GF_Face_Done (gfdrivr.c:145) > by 0x414CA0: open_face (ftobjs.c:1404) > by 0x416971: ft_open_face_internal (ftobjs.c:2447) > by 0x414D53: FT_New_Face (ftobjs.c:1438) > by 0x40AB1B: FTDemo_Install_Font (ftcommon.c:396) > by 0x408B7C: main (ftview.c:1887) > Address 0x200000008 is not stack'd, malloc'd or (recently) free'd > > So you have to find out why this happens. Note that the problem > happens with *any* file not recognized by other drivers as a font. > Yes I will work on it. For example, you can say > > ftview 20 make.log > > to trigger the bug... > > If I remember correctly I also advised you to add calls to the various > `FT_TRACEX' macros, which both helps you and the user in debugging > issues. Now is the time to do that! > Ok. > BTW, what simple program are you using to check whether the GF module > works? For example, have you adapted > > https://www.freetype.org/freetype2/docs/tutorial/example1.c > > to your needs? Please post it. > No, I am not using them. I am directly using ftview to check for its working. > You should work hard to resolve those issues. Second evaluation is > coming soon... > Yes! I will :-) Thanks.
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
