> Armin, Hi Alexei :)
> We have 73 timeouts and counting: > https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Timeout+proj%3Dfreetype2 > > The best solution is to limit the cumulative total to 1 Gb of rendered > bitmaps. Is this hard to implement? This solution would (maybe) remove most timeout reports immediately but it would also silently hide unreached parts of those fuzz targets. I really, really, really want to avoid that. The best solution (IMO) is to take the time and trace lengthy calculations within the targets and make sure that those calculations are kept to a minimum (either by splitting targets or capping certain actions). There has been some progress with that (e.g. capping the maximum glyph render size) and the results are generally promising. It's just not finished yet which is why those timeout reports still exist. Personally, I would treat those reports as temporary, implicit "Won't fix" until I (or someone else) have enough time to carefully examine those timeouts on a per-target level. (I will gladly do that btw, it's only a matter of having enough time at some point .......). At the moment, OSS-Fuzz shows only one of those timeout reports per target until that report gets made public. Only then, a new timeout report for the same target will show up. I think that's not too much noise, compared to the alternative of silently missing parts of fuzz targets. Best Armin _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
