Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)

[Werner LEMBERG]

> My librsvg2 is current - 2.56.0 :-(.
>
> What svg font does it work well with? I think I should do Valgrind
> on a font that works, to see what is leaking.

I use version 2.52.9 as installed by default on my OpenSUSE GNU/Linux
box.  This works fine for simple cases like
`ArefRuqaaInk-Regular.ttf`, but rendering glyphs from a recent
'NotoColorEmoji-Regular.ttf' version font takes ages.

> Found "-k czq 500" is okay, but "-k czq 400" fails 5 times on out of
> memory, and leaks in cairo_recording_surface_create from
> FT_Glyph_To_Bitmap, according to valgrind.

Please give more details, using valgrind options `--leak-check=full`
and `--show-leak-kinds=all` together with setting environment variable
`FT2_DEBUG=any:7`.

>  "-k czq 380" is just not runnable (and valgrind warns of "set
> address range perms: large range" too).  The out of memory happens
> between 477 and 478.

Interesting.  Calling

```
FT2_DEBUG=any:7 \
valgrind --leak-check=full \
         --show-leak-kinds=all \
  ftview -kczq 380 ArefRuqaaInk-Regular.ttf \
  &> ArefRuqaaInk-Regular.log
```

I see

```
HEAP SUMMARY:
  in use at exit: 292,853 bytes in 1,105 blocks
  total heap usage: 4,526 allocs, 3,421 frees, 4,406,385 bytes allocated
```

in the output, which looks OK to me.

> I am wondering also that because the arabic font means negative
> advance widths for most glyphs, and due to an over-sight, any glyphs
> other than the first few get those negative advance widths passed to
> cairo as widths :-( , so the rsvg port code is doing some insanely
> large numbers from wrap around, for small negative bitmaps....

Please file a bug report with all the gory details.


    Werner