[SOLVED] kdenlive - segmentation fault

I'm using an up to date 14.2, KDE4 and multilib with about a 100 SBo packages.

When I start kdenlive, from the desktop, I get an error box pop up with the message

Executable: kdenlive PID: 3098 Signal: Segmentation fault (11) Time: 03/09/2020 08:42:20

From the command line I get

KCrash: Application 'kdenlive' crashing... KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit KCrash: Connect sock_file=/home/alex/.kde/socket-green/kdeinit4__0 [1] + Stopped (SIGSTOP) kdenlive [1] + Done(253) kdenlive

I'm not a frequent user of kdenlive. I know it was working in 2015, which was probably on Slackware 14.1. I have three other boxes where kdenlive starts without issue. None of these boxes have ever fired up kdenlive before and all are on Slackware 14.2.

Because of upgrades to it's dependencies I've recompiled kdewnlive 16 times, since 2016, and as recently as 23rd August 2020.

I've moved out of the way these configuration files

mv ./share/config/kdenliverc ./share/config/kdenliverc.bak
mv ./share/apps/kdenlive ./share/apps/kdenlive.bak
mv ./data/stalefiles/kdenlive ./data/stalefiles/kdenlive.bak

Started up kdenlive and get the same segmentation fault.

I've recompiled all the kdenlive dependencies namely

faad2 recordmydesktop gsm lame dvdauthor dvgrab schroedinger x264 xvidcore faac mlt amrnb libavc1394 libdv libiec61883 libquicktime ffmpeg

Then recompiled kdenlive.

Same segmentation fault.


The file /usr/lib64/kde4/libexec/drkonqi is part of

-rw-r--r-- 1 root root 93820 Oct 21 2016 kde-runtime-4.14.3-x86_64-3


My workaround is to do the kdenlive on one of the boxes where it does work. I can even do the work on a machine that has Slackware Current installed as kdenlive starts successfully. Doing the workaround, without knowing what the problem is, seems like cheating!

Alex

Do you have qt5 installed? If so, try removing it and building from mlt to kdenlive (so it builds against qt4) and then reinstall qt5 after (you could save the qt5 package so you don't have to keep recompiling the beast).

I'm not running kdenlive from SBo anymore (as it's included in ktown), but I remember this qt4/5 problem when I was compiling it.

Why not try Belnder?

Originally Posted by drgibbon Do you have qt5 installed? If so, try removing it and building from mlt to kdenlive (so it builds against qt4) and then reinstall qt5 after (you could save the qt5 package so you don't have to keep recompiling the beast). I'm not running kdenlive from SBo anymore (as it's included in ktown), but I remember this qt4/5 problem when I was compiling it.

I've

• swapped kdenlive between seg faulting machine and working machine. Seg faulting machine still seg faults and working machine still works
• uninstalled kdenlive and qt5. Recompiled kdenlive and kdenlive started successfully.
• reinstalled qt5 and the segmentation fault returns. Conclude that the problem maybe with qt5
• removed qt5 again. kdenlive started successfully.
• installed the qt5 package from my working machine. Got the segmentation fault.
• reinstalled an old qt5-5.6.1-x86_64-1_SBo.tgz. kdenlive started successfully.
• reinstalled an old qt5-5.9.8-x86_64-2_SBo.tgz. kdenlive started successfully.
• reinstalled the latest package qt5-5.12.8-x86_64-1_SBo.tgz. segmentation fault.

Looked for differences betwee how qt5 was compiled on the different machines and found this -
Machine with segmentation fault

Checking for PCRE2... Trying source 0 (type pkgConfig) of library pcre2 ... + /usr/bin/pkg-config --exists --silence-errors libpcre2-16 pkg-config did not find package. => source produced no result. Trying source 1 (type inline) of library pcre2 ... None of [libpcre2-16.so libpcre2-16.a] found in [] and global paths. => source produced no result. test config.qtbase_corelib.libraries.pcre2 FAILED

Working machine

Checking for PCRE2... Trying source 0 (type pkgConfig) of library pcre2 ... + /usr/bin/pkg-config --exists --silence-errors libpcre2-16 + /usr/bin/pkg-config --modversion libpcre2-16 > 10.35 + /usr/bin/pkg-config --libs-only-L libpcre2-16 + /usr/bin/pkg-config --libs-only-l libpcre2-16 > -lpcre2-16 + /usr/bin/pkg-config --cflags libpcre2-16 + cd /home/packages/tmp/SBo/qt-everywhere-src-5.12.8/config.tests/pcre2 && /home/packages/tmp/SBo/qt-everywhere-src-5.12.8/qtbase/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" 'QMAKE_USE += pcre2' 'QMAKE_LIBS_PCRE2 = /usr/lib64/libpcre2-16.so' /home/packages/tmp/SBo/qt-everywhere-src-5.12.8/config.tests/pcre2 + cd /home/packages/tmp/SBo/qt-everywhere-src-5.12.8/config.tests/pcre2 && MAKEFLAGS= /usr/bin/gmake > g++ -c -pipe -O2 -O2 -fPIC -std=gnu++11 -w -fPIC -I. -I/home/packages/tmp/SBo/qt-everywhere-src-5.12.8/qtbase/mkspecs/linux-g++ -o main.o main.cpp > g++ -Wl,-O1 -L/usr/lib64 -o pcre2 main.o /usr/lib64/libpcre2-16.so => source accepted. test config.qtbase_corelib.libraries.pcre2 succeeded

Recompiled qt5 on segmentation machine and kdenlive still failed with segmentation fault!

Removed the package pcre2. kdenlive started successfully.

I remembered that I introduced pcre2 to my system because it had become a new dependency to R. Did this on 22nd August 2020. Correct time frame.

The SlackBuild.org description for pcre2 is

PCRE2 is a re-working of the original PCRE library to provide an entirely new API.

Maybe a clue there as to why I'm getting the segmentation fault.

I tried compiling qt5 with the -pcre flag. No joy as irrespective of whether I had pcre2 installed or not I got the error

ERROR: Invalid value 'yes' supplied to command line option 'pcre'.

I'm wondering whether a newer version of qt5 will solve this issue. Though I still can't understand why I can't get both machines to deliver a segmentation fault. Must be some subtle difference in the way I've installed/upgraded kdenline/qt5/pcre2.

Alex

Still can't work out why kdenlive works on 3 machines, but gets a segmentation fault on another machine

Current way forward is to

1. remove the package pcre2
2. recompile R using the --with-pcre1 flag

I'm sure that R will fail at some time in the future when the R developers remove support for pcre1


Alex

Pushed on with this and had another look at pcre2 as I'd said previously

Removed the package pcre2. kdenlive started successfully.

So I had a look at pcre2.SlackBuild an though it made no sense whatsover removed the config flag --enable-pcre2-16 and viola I could get kdenlive to start. Not bad with a one line change to pcre2.Slackbuild.

--enable-pcre2-16 is described as

enable 16 bit character support

Can't see why this should make a difference.

Recompiled kdenlive and R everything still OK no segmentation fault.

Recompiling qt5 to see if that throws up any problems.

If qt5 compiles successfully only need to understand why removing the --enable-pcre2-16 made the difference. Also how long lasting will it be.

Originally Posted by aikempshall So I had a look at pcre2.SlackBuild an though it made no sense whatsover removed the config flag --enable-pcre2-16 and viola I could get kdenlive to start. Not bad with a one line change to pcre2.Slackbuild. --enable-pcre2-16 is described as Can't see why this should make a difference.

Might be worth submitting a bug report to kdenlive. It might be something easy they can fix or it might be something where they purposefully removed 16bit character support. Either way, it might be nice to make sure.

Originally Posted by bassmadrigal Might be worth submitting a bug report to kdenlive. It might be something easy they can fix or it might be something where they purposefully removed 16bit character support. Either way, it might be nice to make sure.

kdenlive in SlackBuilds,org for 14.2 is on version 0.9.10 circa 2014.


The problem started with the introduction of pcre2 because it became a prerequisite of R.

The introduction of pcre2 caused kdenlive to segfault

Application: Kdenlive (kdenlive), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [KCrash Handler] #6 0x00007fd80acc5877 in QMetaObject::className() const () at /usr/lib64/libQt5Core.so.5 #7 0x00007fd80972c307 in () at /usr/lib64/libQt5Widgets.so.5 #8 0x00007fd8096d0a77 in () at /usr/lib64/libQt5Widgets.so.5 #9 0x00007fd809a2e956 in () at /usr/lib64/libQt5Widgets.so.5 #10 0x0000006e0000005b in () #11 0x00000000015abb90 in () #12 0x0000000000000005 in () #13 0x00007fd8096c7df7 in _init () at /usr/lib64/libQt5Widgets.so.5 #14 0x00007fd80b1ea248 in () at /usr/lib64/mlt/libmltqt.so #15 0x00007fd83d23d61a in call_init.part () at /lib64/ld-linux-x86-64.so.2 #16 0x00007fd83d23d76b in _dl_init () at /lib64/ld-linux-x86-64.so.2 #17 0x00007fd83d242858 in dl_open_worker () at /lib64/ld-linux-x86-64.so.2 #18 0x00007fd83d23d504 in _dl_catch_error () at /lib64/ld-linux-x86-64.so.2 #19 0x00007fd83d241d59 in _dl_open () at /lib64/ld-linux-x86-64.so.2 #20 0x00007fd83a22cf09 in dlopen_doit () at /lib64/libdl.so.2 #21 0x00007fd83d23d504 in _dl_catch_error () at /lib64/ld-linux-x86-64.so.2 #22 0x00007fd83a22d571 in _dlerror_run () at /lib64/libdl.so.2 #23 0x00007fd83a22cfa1 in dlopen@@GLIBC_2.2.5 () at /lib64/libdl.so.2 #24 0x00007fd83a677a14 in mlt_repository_init () at /usr/lib64/libmlt.so.6 #25 0x00007fd83a6771a8 in mlt_factory_init () at /usr/lib64/libmlt.so.6 #26 0x00007fd83a443c2b in Mlt::Factory::init(char const*) () at /usr/lib64/libmlt++.so.3 #27 0x00000000006c412f in () #28 0x00000000007a2252 in () #29 0x0000000000477688 in () #30 0x00007fd835eab7d0 in __libc_start_main () at /lib64/libc.so.6 #31 0x0000000000477c09 in _start ()

I've found this thread from 2017 https://www.linuxquestions.org/quest...t5-4175604501/. I got kdenlive to run successfully in an untainted 14.2 with just the basic prereqs for kdenlive installed. kdenlive doesn't need multilib, R, qt5 or pcre2 so I've didn't install these. Ported the working package to a machine containing qt5 and it still seq faulted.

What I'm trying to understand is why the path to the segmentation fault includes /usr/lib64/libQt5Core.so.5

The reason why I needed to run kdenlive has gone away. Even the reason hadn't gone away I've got a machine with 14.2+ installed with ktown and multilib. Could have run it there.

As far as I can work out qt5 is needed, on 14.2, for fritzing and qt-creator. I use these tools far more than I use kdenlive. I don't think I need R at all, must have at one time.

So this weekend's task is to uninstall R and pcre2 and see what happens.

I starting to wonder if it's time to bite the bullet and upgrade to 14.2+. The steepest learning curve was getting to grips with slackpkg+. The other worry is that can I cope with the churn rate on 14.2+. So far this year there have been over 1,000 updates whereas on 14.2 there have been only 30. I can't have a situation of an outage on Monday through Friday.

I had another look at the backtrace for the kdenlive segmentation fault and went further back concentrating on the steps before the calls to /usr/lib64/libQt5Widgets.so.5 which was /usr/lib64/mlt/libmltqt.so

Had a look at the build script for mlt and spotted this

# Use qt5 if present, otherwise system default if pkg-config --exists Qt5 ; then qt="--qt-libdir=$(pkg-config Qt5 --variable=libdir) --qt-includedir=$(pkg-config Qt5 --variable=headerdir)" else qt="--qt-libdir=$(pkg-config Qt --variable=libdir) --qt-includedir=$(pkg-config Qt --variable=headerdir)" fi

This didn't look right to me as I'm running on 14.2 whose primary qt is QT4 but also has QT5 installed. So I changed the SlackBuild to always default to QT4 if available

if pkg-config --exists Qt ; then qt="--qt-libdir=$(pkg-config Qt --variable=libdir) --qt-includedir=$(pkg-config Qt --variable=headerdir)" elif pkg-config --exists Qt5 ; then qt="--qt-libdir=$(pkg-config Qt5 --variable=libdir) --qt-includedir=$(pkg-config Qt5 --variable=headerdir)" fi

Compiled mlt and kdenlive.

Kdenlive no longer had the segmentation fault!

Good to hear, so yes it's mlt building against qt5 that causes the problem (removing qt5 before compiling mlt etc should work too).

Originally Posted by bassmadrigal Might be worth submitting a bug report to kdenlive. It might be something easy they can fix or it might be something where they purposefully removed 16bit character support. Either way, it might be nice to make sure.

I doubt upstream will look at a bug report. They've moved on to QT5, KDE Frameworks 5 along with the a new MLT, and anything older is deprecated. Changing MLT to fix kdenlive may also result in breakage of shotcut and flowblade on SBo.

Thus, I may instead move to a QT5=[yes | no] switch with a note in kdenlive README to compile MLT with QT5=no (default).

Originally Posted by kingbeowulf I doubt upstream will look at a bug report. They've moved on to QT5, KDE Frameworks 5 along with the a new MLT, and anything older is deprecated. Changing MLT to fix kdenlive may also result in breakage of shotcut and flowblade on SBo. Thus, I may instead move to a QT5=[yes | no] switch with a note in kdenlive README to compile MLT with QT5=no (default).

Probably best for the mlt.SlackBuild script to stay as is. I've got several of these that diverge from the original scripts in SlackBuilds.org and I patch them on the fly.

I'm not a user of shotcut or flowblade.

The important thing is that this thread will be useful to someone in the future. Even if it is just to encourage them to look further down the back trace for the source of the error and to share the back trace. I wasted a lot of my time and everybody else's in not including the back trace in the initial posting.

I am running -current and use kdenlive rather heavily some times for editing.
There might be better tools but it works fine for my mostly cut-paste-render needs.
The version supplied by the slackbuild is an ancient version.
I have also had trouble with the versions supplied with plasma5 at times
although I am highly appreciative of ktown (!).
I have moved to the appimage copied into /opt and it works crisp and fine.
Presently it is kdenlive-20.08.1-x86_64.