Bug 1867377 - mlt crashes (core dump) with every rendering attempt
Summary: mlt crashes (core dump) with every rendering attempt
Alias: None
Product: Fedora
Classification: Fedora
Component: mlt
Version: 32
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Sergio Basto
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-08-09 11:55 UTC by Martin Ueding
Modified: 2020-09-03 08:33 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-09-03 08:33:58 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
KDE Software Compilation 424759 0 NOR RESOLVED mlt crashes (core dump) with every rendering attempt 2020-09-02 22:29:30 UTC

Description Martin Ueding 2020-08-09 11:55:05 UTC
# Description of problem

I tried to render a video with Kdenlive but it always crashes. I can find the following stack trace in the system journal:

Jul 28 09:52:34 mu-x220 systemd-coredump[82646]:
  Process 82642 (mlt-melt) of user 1000 dumped core.
  Stack trace of thread 82642:
  #0  0x00007f5b859ad9e5 raise (libc.so.6 + 0x3c9e5)
  #1  0x00007f5b85996895 abort (libc.so.6 + 0x25895)
  #2  0x00007f5b7d8f1a7f _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5 + 0x91a7f)
  #3  0x00007f5b7de65e85 _ZN13QFontDatabaseC2Ev.cold (libQt5Gui.so.5 + 0xeae85)
  #4  0x00007f5b746ca5cb _ZL5fontsv (libpbf.so + 0x2e5cb)
  #5  0x00007f5b746caa85 _ZN4Font13fromJsonArrayERK10QJsonArray (libpbf.so + 0x2ea85)
  #6  0x00007f5b746ba879 _ZN5Style5Layer6LayoutC1ERK11QJsonObject (libpbf.so + 0x1e879)
  #7  0x00007f5b746beee7 _ZN5Style5LayerC1ERK11QJsonObject (libpbf.so + 0x22ee7)
  #8  0x00007f5b746c08a0 _ZN5Style4loadERK7QString (libpbf.so + 0x248a0)
  #9  0x00007f5b746b5a88 _ZN9PBFPluginC2Ev (libpbf.so + 0x19a88)
  #10 0x00007f5b746d5375 qt_plugin_instance (libpbf.so + 0x39375)
  #11 0x00007f5b7dab3564 _ZN15QLibraryPrivate14pluginInstanceEv (libQt5Core.so.5 + 0x253564)
  #12 0x00007f5b7daae16d _ZNK14QFactoryLoader8instanceEi (libQt5Core.so.5 + 0x24e16d)
  #13 0x00007f5b7def0fa6 _ZL23createReadHandlerHelperP9QIODeviceRK10QByteArraybb (libQt5Gui.so.5 + 0x175fa6)
  #14 0x00007f5b7def1d84 _ZN19QImageReaderPrivate11initHandlerEv (libQt5Gui.so.5 + 0x176d84)
  #15 0x00007f5b7def27e0 _ZNK12QImageReader7canReadEv (libQt5Gui.so.5 + 0x1777e0)
  #16 0x00007f5b7ebc17fa init_qimage (libmltqt.so + 0x167fa)
  #17 0x00007f5b7ebbcdf5 producer_qimage_init (libmltqt.so + 0x11df5)
  #18 0x00007f5b85cf6542 mlt_factory_producer (libmlt.so.6 + 0x29542)
  #19 0x00007f5b7ea5308e create_producer (libmltcore.so + 0xa08e)
  #20 0x00007f5b7ea536a9 producer_loader_init (libmltcore.so + 0xa6a9)
  #21 0x00007f5b85cf6542 mlt_factory_producer (libmlt.so.6 + 0x29542)
  #22 0x00007f5b85d17c90 on_end_element (libmltxml.so + 0x9c90)
  #23 0x00007f5b856a10cd xmlParseEndTag1.constprop.0 (libxml2.so.2 + 0x4a0cd)
  #24 0x00007f5b856a11c4 xmlParseElementEnd (libxml2.so.2 + 0x4a1c4)
  #25 0x00007f5b856a5721 xmlParseContent (libxml2.so.2 + 0x4e721)
  #26 0x00007f5b856a6dc0 xmlParseDocument (libxml2.so.2 + 0x4fdc0)
  #27 0x00007f5b85d18dce producer_xml_init (libmltxml.so + 0xadce)
  #28 0x00007f5b85cf6542 mlt_factory_producer (libmlt.so.6 + 0x29542)
  #29 0x00007f5b7ea532a1 create_producer (libmltcore.so + 0xa2a1)
  #30 0x00007f5b7ea536a9 producer_loader_init (libmltcore.so + 0xa6a9)
  #31 0x00007f5b85cf6542 mlt_factory_producer (libmlt.so.6 + 0x29542)
  #32 0x00007f5b7ea547fa producer_melt_init (libmltcore.so + 0xb7fa)
  #33 0x00007f5b85cf6542 mlt_factory_producer (libmlt.so.6 + 0x29542)
  #34 0x0000558ec88772b5 main (mlt-melt + 0x32b5)
  #35 0x00007f5b85998042 __libc_start_main (libc.so.6 + 0x27042)
  #36 0x0000558ec887838e _start (mlt-melt + 0x438e)

# Version-Release number of selected component (if applicable)

Linux/KDE Plasma: Fedora 32
KDE Plasma Version: 20.04.1
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2

# How reproducible

Apparently always, every export format that I tried within that project crashed the same way.

# Additional info

Reporting the bug with abrt did not work, apparently the servers were being migrated.

I have already [filed that bug with KDE](https://bugs.kde.org/show_bug.cgi?id=424759) as [suggested on Ask Fedora](https://ask.fedoraproject.org/t/mlt-framework-crash-via-kdenlive-rendering/8475).

There I was asked to try the AppImage 20.04b. Using that I was able to export the video just fine. There must be an issue in the Fedora packaging then.

Comment 1 Sergio Basto 2020-08-09 12:07:02 UTC
you should install kdenlive from RpmFusion and be sure that mlt-freeworld is installed

Comment 2 Martin Ueding 2020-08-09 12:27:30 UTC
I actually have `kdenlive-20.04.3-1.fc32.src.rpm` and `mlt-freeworld-6.20.0-1.fc32.src.rpm` installed from RPM Fusion.

Comment 3 Fedora Update System 2020-08-22 12:38:04 UTC
FEDORA-2020-eba98725a8 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-eba98725a8

Comment 4 Fedora Update System 2020-08-29 16:48:27 UTC
FEDORA-2020-eba98725a8 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Sergio Basto 2020-09-02 22:31:09 UTC
(In reply to Martin Ueding from comment #2)
> I actually have `kdenlive-20.04.3-1.fc32.src.rpm` and
> `mlt-freeworld-6.20.0-1.fc32.src.rpm` installed from RPM Fusion.

Thank you for the report , Did you have time to test the new versions of mlt and kdenlive?

Comment 6 Martin Ueding 2020-09-03 08:13:48 UTC
It indeed works again! Thanks!

I wasn't sure which status it should now have, I didn't find “fixed”.

Comment 7 Sergio Basto 2020-09-03 08:33:58 UTC

Note You need to log in before you can comment on or make changes to this bug.