Bug 1567633

A fuller backtrace of the assertion:

#0  0x00007ffff33fbf7b in raise () from /lib64/libc.so.6
#1  0x00007ffff33e65c1 in abort () from /lib64/libc.so.6
#2  0x00007ffff33e6491 in __assert_fail_base.cold.0 () from /lib64/libc.so.6
#3  0x00007ffff33f46e2 in __assert_fail () from /lib64/libc.so.6
#4  0x00007ffff6976928 in _cairo_ft_unscaled_font_create_internal (
    from_face=from_face@entry=1, filename=filename@entry=0x0, id=id@entry=0, 
    font_face=<optimized out>, out=out@entry=0x7fffffffb448)
    at cairo-ft-font.c:576
#5  0x00007ffff6977881 in _cairo_ft_unscaled_font_create_from_face (
    out=0x7fffffffb448, face=<optimized out>) at cairo-ft-font.c:3707
#6  cairo_ft_font_face_create_for_ft_face (face=<optimized out>, load_flags=2)
    at cairo-ft-font.c:3707
#7  0x00007ffff7709df7 in mapnik::cairo_face::cairo_face(std::shared_ptr<mapnik::font_library> const&, std::shared_ptr<mapnik::font_face> const&) ()
   from /lib64/libmapnik.so.3.0
#8  0x00007ffff770a11e in mapnik::cairo_face_manager::get_face(std::shared_ptr<mapnik::font_face>) () from /lib64/libmapnik.so.3.0
#9  0x00007ffff770a2e2 in mapnik::cairo_context::set_font_face(mapnik::cairo_face_manager&, std::shared_ptr<mapnik::font_face>) () from /lib64/libmapnik.so.3.0
#10 0x00007ffff770a543 in mapnik::cairo_context::add_text(mapnik::glyph_positions const&, mapnik::cairo_face_manager&, mapnik::composite_mode_e, mapnik::composite_mode_e, double) () from /lib64/libmapnik.so.3.0
#11 0x00007ffff770f30e in mapnik::cairo_renderer<std::shared_ptr<_cairo> >::process(mapnik::text_symbolizer const&, mapnik::feature_impl&, mapnik::proj_transform const&) () from /lib64/libmapnik.so.3.0

I think this stems from https://cgit.freedesktop.org/cairo/commit/?id=42f07ef9037ea871dc0e58200437aab9c702ad6d which changed the key generation for the unscaled face to use face->face_index as the id.

In _cairo_ft_unscaled_font_create_internal the hash for the original is created using id (zero in this case) and then the new unscaled face is created but using a different id to generate the hash. It was always different but previously was zero which did match and is now the face index which doesn't.

Created attachment 1423211 [details]
Test case

So this happens when a font has multiple faces in the same file and you try and create a cairo face from a freetype face with a non-zero index.

A minimal test case is attached.

Thanks, I backported the upstream fix to cairo-1.15.12-2.fc28 now.

cairo-1.15.12-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f6b5861387

cairo-1.15.12-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f6b5861387

Proposed as a Freeze Exception for 28-final by Fedora user pwalter using the blocker tracking app because:

 Would be nice to include this fix as a FE as it fixes a common crash. Shouldn't have any side effects as it's just a tiny patch fixing the crash.

+1 as a FE from me.

+1 FE I guess... do we know if anything except mapnik hits it?

I don't see any indication of that either here or in the upstream bug (https://bugs.freedesktop.org/show_bug.cgi?id=105746 )...I mean, from the description it sounds like other things *could* hit it, but I don't see any definite reports that they *do* yet.

<kalev-afk> adamw: I haven't heard of anything else besides mapnik hitting it
<kalev-afk> adamw: seems fine to me to leave it for a post-GA update

Given that, I'm -1.

Yeah, I will change to -1 if it's just mapnik. We can fix that in a update.

Yeah, I will change to -1 if it's just mapnik. We can fix that in a update.

Gonna call this rejected for now, just to clean up the list.

cairo-1.15.12-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.