Re: [ft-devel] [GSoC] Plans for the Finale of Fuzzing for FreeType
> Hi Armin, Hi pat, great to see you :D > My graduate student Zeming has been making good progress this term on TTF > bytecode analysis. So we don't have a corpus, but we can now easily manipulate > bytecode for existing fonts. If there's anything specific you have in mind, we > should figure out whether we can make that happen. Oh cool! Feel free to use any fonts that are suitable for you in https://github.com/cherusker/freetype2-testing/tree/master/fuzzing/corpora :) A quick wish list: - fonts that contain (small) glyph bitmaps (all drivers) - fonts with kerning information that can be accessed via FreeType (drivers: CFF, PFR, TrueType, Type 1) - fonts that contain multiple masters / font variations (drivers: CFF, TrueType, Type 1) - CID-keyed fonts (drivers: CID Type 1, CFF) - fonts that explore unicode variation sequences (https://www.freetype.org/freetype2/docs/reference/ft2-glyph_variants.html) (all drivers) All fonts should be really small: they should only contain a handful of glyphs (just enough to cover different/edgy aspects within a font). Small does not imply "simple" however: "complicated" fonts of any shape and form are welcome (many faces, many instances, combination of many aspects, ...). Furthermore, if possible, fonts should be licensed with the SIL Open Font License. These are really the most important aspects at the moment; thank you so much upfront for looking into this :) Armin ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [GSoC] Plans for the Finale of Fuzzing for FreeType
Hi Armin, On Tue, Jul 10, 2018 at 1:04 PM, wrote: > Does anyone know font geeks? > === > > If possible, I would love to ditch the "old" corpus since its fonts are huge > (they are proper fonts) and repetitive (not exactly the initial fuzz corpus > of your dreams). While I do know more/less exactly what the perfect fuzzing > fonts should look like, I would much rather spend my time improving and > expanding the fuzz targets than creating those fonts. So, if there are any > font enthusiasts listening (or if you know any people who would love doing > that) please step forward; that would really be a great help :) > > Ben (bungeman) already did a great job in providing a base set of sample > fonts that are optimised for fuzzing (small fonts, few glyphs, concentrating > on a few, very distinctive features) but there could be a lot more > (https://github.com/cherusker/freetype2-testing/tree/master/fuzzing/corpora/ > truetype/bungeman etc.). > > For reference: I will also contact HarfBuzz and see if they have interesting > stuff and IF they do, if they would share that with FreeType :) My graduate student Zeming has been making good progress this term on TTF bytecode analysis. So we don't have a corpus, but we can now easily manipulate bytecode for existing fonts. If there's anything specific you have in mind, we should figure out whether we can make that happen. pat ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problems with gfdriver in ftview.
>> Well, simply follow the documentation, i.e., set `pitch' to >> >> w + 7) / 8) + 1) / 2) * 2 >> >> (but with some better C code :-) and use this value for creating >> the bitmap. > > Ok, I did change the value of pitch (6) and tried to draw `a', it is > giving a wrong glyph, then I changed the value to previous value(5), > it drew a correct one. I think that this might be the problem, that > gf uses odd pitch value to draw glyph and ftview requires a even > one? With `set the pitch' I mean of course that you also adjust the code to insert a trailing null byte each line *in the output buffer* if the number of input bytes per line is uneven... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [GSoC] Plans for the Finale of Fuzzing for FreeType
Hello dear readers of this wonderful mailing list :) I want to give you a quick update on the fuzzing side of things: The targets are growing on a daily basis and will be integrated into OSS-Fuzz in a matter of hours, maximum a day or two :) They will not be complete by then (technically, they will never be complete) but they are in such a state that Kostya and I decided it's worth throwing them into the machinery and watch the outcome. Apart from that, I plan to achieve the following things during the 3rd (and final) stage of GSoC 2018 (I am so sad, I cannot believe it's more than 50% over already :/) (1) Further work on the API checklist (https://github.com/cherusker/freetype2-testing/blob/master/fuzzing/README.m d) and adding even more API functions to that list (esp. parts of the "Support API" that is not sufficiently being used indirectly). (2) Play with driver properties. (3) Build another set of fuzz targets for fuzzing glyph related stuff (stroking, rendering, ...) that happens independently of the driver-driven targets (that are the actual focus of my GSoC project). Some things from the driver-driven targets will then be moved to these glyph-driven targets. (4) Integrate some profiling to identify bottlenecks and maybe put scary bits into separate targets and/or isolate them otherwise (if necessary). So far, so good. I hope you're still with me, b/c I do also have a question for everyone in here: Does anyone know font geeks? === If possible, I would love to ditch the "old" corpus since its fonts are huge (they are proper fonts) and repetitive (not exactly the initial fuzz corpus of your dreams). While I do know more/less exactly what the perfect fuzzing fonts should look like, I would much rather spend my time improving and expanding the fuzz targets than creating those fonts. So, if there are any font enthusiasts listening (or if you know any people who would love doing that) please step forward; that would really be a great help :) Ben (bungeman) already did a great job in providing a base set of sample fonts that are optimised for fuzzing (small fonts, few glyphs, concentrating on a few, very distinctive features) but there could be a lot more (https://github.com/cherusker/freetype2-testing/tree/master/fuzzing/corpora/ truetype/bungeman etc.). For reference: I will also contact HarfBuzz and see if they have interesting stuff and IF they do, if they would share that with FreeType :) I hope everyone is doing great and to my GSoC co-workers: have a happy coding finale :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problems with gfdriver in ftview.
> > > [...] I still have a doubt about pitch value, currently it is set to > > (w+7) / 8 (w: glyph width ). The documentation says `For the B/W > > rasterizer, ‘pitch’ is always an even number.' but this is also > > returning odd values. Is there any problem in this? > > Well, simply follow the documentation, i.e., set `pitch' to > > w + 7) / 8) + 1) / 2) * 2 > > (but with some better C code :-) and use this value for creating the > bitmap. > Ok, I did change the value of pitch (6) and tried to draw `a', it is giving a wrong glyph, then I changed the value to previous value(5), it drew a correct one. I think that this might be the problem, that gf uses odd pitch value to draw glyph and ftview requires a even one? Thank you Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problems with gfdriver in ftview.
> [...] I still have a doubt about pitch value, currently it is set to > (w+7) / 8 (w: glyph width ). The documentation says `For the B/W > rasterizer, ‘pitch’ is always an even number.' but this is also > returning odd values. Is there any problem in this? Well, simply follow the documentation, i.e., set `pitch' to w + 7) / 8) + 1) / 2) * 2 (but with some better C code :-) and use this value for creating the bitmap. >> What git commit ID of the `freetype2-demos' repository are you >> using? > > I am using freetype2-demos' VER 2.9.1. OK, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problems with gfdriver in ftview.
> > > I have removed all the memory leak errors in the gf driver. But now > > when I run `ftview', it is still not loading the glyphs. > > Before delving into this issue: Does your `ftexample' now work > correctly? > Yes, I can't say for sure as I didn't draw every glyph by the gdb method (It takes a lot of time too.), but I changed the values of rows and width and now it seems correct, I still have a doubt about pitch value, currently it is set to (w+7) / 8 (w: glyph width ). The documentation says `For the B/W rasterizer, ‘pitch’ is always an even number.' but this is also returning odd values. Is there any problem in this? I thought that ftview had problems because of memory leak errors in gfdriver, that is why I asked this problem. > > ==11084== Invalid read of size 1 > > ==11084==at 0x10E758: my_face_requester (ftcommon.c:221) > > What git commit ID of the `freetype2-demos' repository are you using? > I am using freetype2-demos' VER 2.9.1. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problems with gfdriver in ftview.
> I have removed all the memory leak errors in the gf driver. But now > when I run `ftview', it is still not loading the glyphs. Before delving into this issue: Does your `ftexample' now work correctly? > ==11084== Invalid read of size 1 > ==11084==at 0x10E758: my_face_requester (ftcommon.c:221) What git commit ID of the `freetype2-demos' repository are you using? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Problems with gfdriver in ftview.
Hi all, I have removed all the memory leak errors in the gf driver. But now when I run `ftview', it is still not loading the glyphs. I did `valgrind ftview 20 /home/parth/cmr10 .600gf' and it is showing invalid reads in the `FTC...' functions. I am not able to understand the problem. Please help. This is what I am getting: ==11084== Memcheck, a memory error detector ==11084== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==11084== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==11084== Command: ftview 20 /home/parth/cmr10.600gf ==11084== FT_Open_Face: Requesting number of faces and named instances FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_Open_Face: The font has 1 face and 0 named instances for face 0 FT_Open_Face: Return 0x0 FT_Open_Face: Requesting number of faces and named instances FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_Open_Face: The font has 1 face and 0 named instances for face 0 FT_Open_Face: Return 0x0 FT_Open_Face: Requesting face 0 FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] not a BDF file GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_New_GlyphSlot: Creating new slot object FT_New_GlyphSlot: Return 0x0 FT_Open_Face: Creating size object FT_Open_Face: Return 0x0 FT_Open_Face: Requesting face 0 FT_Stream_Open: opened `/home/parth/cmr10.600gf' (24148 bytes) successfully TTF driver SFNT driver not a font using the SFNT container format [...] not a BDF file GF driver gf_load_font: GF_ID(131) found gf_load_font: GF_POST_POST(249) found gf_load_font: GF Postamble found gf_load_font: Allocated bitmap table number of glyphs: allocated 128 FT_Open_Face: New face object, adding to list FT_Open_Face: Creating glyph slot FT_New_GlyphSlot: Creating new slot object FT_New_GlyphSlot: Return 0x0 FT_Open_Face: Creating size object FT_Open_Face: Return 0x0 ==11084== Invalid read of size 1 ==11084==at 0x10E758: my_face_requester (ftcommon.c:221) ==11084==by 0x4EC0836: ftc_face_node_init (ftcmanag.c:243) ==11084==by 0x4EBF8D6: FTC_MruList_New (ftcmru.c:269) ==11084==by 0x4EC1A0E: FTC_Manager_LookupFace (ftcmanag.c:325) ==11084==by 0x10F81B: FTDemo_Set_Current_Charsize (ftcommon.c:601) ==11084==by 0x10D790: event_font_change (ftview.c:1007) ==11084==by 0x10B39C: main (ftview.c:1832) ==11084== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==11084== ==11084== ==11084== Process terminating with default action of signal 11 (SIGSEGV) ==11084== Access not within mapped region at address 0x0 ==11084==at 0x10E758: my_face_requester (ftcommon.c:221) ==11084==by 0x4EC0836: ftc_face_node_init (ftcmanag.c:243) ==11084==by 0x4EBF8D6: FTC_MruList_New (ftcmru.c:269) ==11084==by 0x4EC1A0E: FTC_Manager_LookupFace (ftcmanag.c:325) ==11084==by 0x10F81B: FTDemo_Set_Current_Charsize (ftcommon.c:601) ==11084==by 0x10D790: event_font_change (ftview.c:1007) ==11084==by 0x10B39C: main (ftview.c:1832) ==11084== If you believe this happened as a result of a stack ==11084== overflow in your program's main thread (unlikely but ==11084== possible), you can try to increase the size of the ==11084== main thread stack using the --main-stacksize= flag. ==11084== The main thread stack size used in this run was 8388608. ==11084== ==11084== HEAP SUMMARY: ==11084== in use at exit: 2,334,374 bytes in 653 blocks ==11084== total heap usage: 1,496 allocs, 843 frees, 3,811,806 bytes allocated ==11084== ==11084== LEAK SUMMARY: ==11084==definitely lost: 0 bytes in 0 blocks ==11084==indirectly lost: 0 bytes in 0 blocks ==11084== possibly lost: 0 bytes in 0 blocks ==11084==still reachable: 2,334,374 bytes in 653 blocks ==11084== suppressed: 0 bytes in 0 blocks ==11084== Rerun with --leak-check=full to see details of leaked memory ==11084== ==11084== For counts of detected and suppressed errors, rerun with: -v ==11084==
