appstream-builder crashes when generating metadata for Mageia Cauldron x86_64 core/release

[Conan-Kudo]

In Mageia bug 18669 (the bug for creating AppStream data), one of our sysadmins discovered that appstream-builder 0.6.13 segfaults when processing the metadata with 8 threads.

The output/crash log: appstream-builder-crashlog.txt

The packages mentioned in the crash log:

• http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/google-noto-sans-bengali-ui-fonts-20150417-2.mga6.noarch.rpm
• http://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/google-noto-sans-brahmi-fonts-20150417-2.mga6.noarch.rpm

I can't reproduce with my current system (I don't have enough cores to match the 8 thread command), but maybe you have some idea?

[Conan-Kudo]

It wound up only being successful with one thread on the infrastructure server. :(

[Conan-Kudo]

I've filed a separate downstream bug for this issue: Mageia bug 21207

[hughsie]

I see a libfontconfig crash in the backtrace. This was happening for Fedora, and so much so I've started running the extraction in single-thread mode. Since then, no crash. Fonts really are awful.

[Conan-Kudo]

Erk. And we were just talking about how bad fontconfig is at the sprint a couple weeks back...

grumbles

I hate fonts...

[pterjan]

I doubt this will help, but calling FcConfigAppFontClear before FcConfigDestroy at https://github.com/hughsie/appstream-glib/blob/master/libappstream-builder/plugins/asb-plugin-font.c#L693 is not needed as FcConfigDestroy calls FcFontSetDestroy on all the font sets, including app.

More interestingly I have doubts with the comment on https://cgit.freedesktop.org/fontconfig/tree/src/fccfg.c#n36

It stores the "current config" which is shared between threads, for example this call stores the config for the current thread into that static variable https://github.com/hughsie/appstream-glib/blame/master/libappstream-builder/plugins/asb-plugin-font.c#L596

[pterjan]

To expand on my previous comment as this is not obvious,
Thread1 FcConfigSetCurrent(C1) -> C1 is current
Thread2 FcConfigSetCurrent(C2) -> C2 is current
Thread2 FcConfigDestroy(C2) -> no current config

So calling FcConfigSetCurrent doesn't guarantee there will be a current config later while using C1
This shouldn't be a problem as config is used everywhere so the default one should not matter, but I believe it's better to kill that call which is misleading

[ximion]

@pterjan If I recall correctly, I think I tried exactly that in appstream-generator, which made crashes rare, but they still occasionally happened for reasons I didn't investigate much further (I was so annoyed at that time, that I just crammed the font rendering into a synchronized block, which is the way of the D language to ensure a section of code is run exclusively. As a consequence, if you have many fonts, generating AppStream data now takes a bit longer)