Comment 14 for bug 1303516

A couple of initial queries:

Is there any way we can find out what the font was that was being initialised when the crash occurred? I ask because if the font isn't a graphite font, then what was causing a graphite font to try to be created? Looking at the input text being Burmese, I'll assume it's font linked Padauk.

The ppm value of 15024 being passed here in the source stack trace is suspicious (even if divided by 64 it's still 234pt which is a biiiig font). Not that such a big value alone would cause the crash. But has some corruption occurred earlier?

#4 0x00007f3d808922d2 in gr_make_font_with_ops (ppm=15024, appFontHandle=0x67d0d10, font_ops=font_ops@entry=0x7fff72772f50, face=0x2512f20) at /build/buildd/graphite2-1.2.4/src/gr_font.cpp:52

In the main stack trace, the size value here looks suitably crazy but that could be due to some wandering in the long tall grass (although *how* anyone can get malloc to crash quite so impressively is an interesting question in its own right):

#0 _int_malloc (av=0x7f3d8aa5c760 <main_arena>, bytes=1824) at malloc.c:3489
        iters = <optimized out>
        nb = 1840
        idx = 76
        bin = <optimized out>
        victim = 0x67ec860
        size = 39582418614272

Is this implying a post free memory access to mess up the free list? Are there any other reasons that malloc could go crazy like this? I assume a modern malloc doesn't do anything nice like use the last element on the free list for the next malloc? So the corruption and following usage could be far apart?