Re: [ft-devel] fuzz timeouts

[armin]

>> > We have 73 timeouts and counting:
>> > https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Timeout+pro
>> > j%3Dfreetype2
>
>> This solution would (maybe) remove most timeout reports immediately but it
> would also silently hide unreached parts of those fuzz targets.
>
> The blanket approach to loading flags is extremely wasteful. The fuzzing
> without FT_LOAD_RENDER would be so much faster.

All targets without `-render' in their names follow that path very successfully.

> The only productive way to fuzz the rendering is your glyphs-outlines, on the
> other hand.

The question is, if any of the `-render' targets help the other targets 
(`glyphs-outlines' as well as non-`render' targets) with code coverage, which 
they did back in October.  This could be re-evaluated of course.  However, I 
rather have overlaps than gaps, esp. if it is _free_ (for FreeType at least :P).

> Why is this not a solution?

Are you talking about a hard cap on totally (cumulatively) rendered pixels per 
target (e.g. for `glyphs-outlines')?  If so, imagine the target (any target) 
has a multiple subtasks (render modes + sizes) that it executes, one subtask 
after another.  If we introduce a hard cap, that target would categorically 
execute earlier subtasks more often than later subtasks without any feedback 
(no one would know).  Obviously, that's a very bad thing as "luck" decides 
which tasks are done more regularly than others.  The better solution is to 
understand which of the tasks actually take up too much time and put those 
tasks into separate targets (or limit those _specific_ tasks in other ways).