I'm trying to work out what may have caused Kdenlive to go from a relatively stable system yesterday to a completely insane, unusable crash monster today.

I'm using daily builds because I couldn't get the kubuntu-CI or sunab installs to work for me (see bug report)
I've been using the 2015-07-15 build happily for the last week of quite intensive editing. Yesterday everything was working completely as expected (mostly fine, occasional crashes, which is OK thanks to the excellent recovery tool).
Just to check if it was due to the build, I installed the most recent (debian64) build, but the problem remains.

Since yesterday, there have been two changes which I suspect could be responsible for this change:
-Last night I installed Ardour + JACK.
-Today Ubuntu Software Updater installed a new kernel image.
(see image for details)


Here is the terminal output of the last few crashes from the 0715 build: http://pastebin.com/CGgUrcjy
and from the 0722 build: http://pastebin.com/zcD8bs9u

Does anyone have any advice for how I can go back to something that works? I need to fix this urgently!

System:
Ubuntu 15.04
Lenovo s440
Intel® Core™ i7-4500U CPU @ 1.80GHz × 4
7,5 GiB RAM
Intel HD440, AMD Radeon HD 8670

To test if it was the kernel, I switched to the low-latency kernel (still 3.19). It's mostly better... at least, usable between the crashes.
And I turned off audio thumbnails just because that was mentioned in the terminal immediately preceding some crashes.
Is it likely that audio thumbnails have any bearing whatsoever, or am I just being superstitious?

It could have something to do with an upgrade of JACK. I am assuming we are talking about libjack
"JACK is a low-latency sound server, allowing multiple applications to connect to one audio device, and to share audio between themselves."

I know that libjack-dev is a dependency when you build kdenlive from source. So presumably kdenlive interacts with it in someway.
You could try to back out your Jack upgrade.

Hey what is the state of libjack-dev in your install - does the green cross on the screen shot mean the package is broken ?

It is for reasons like this that I have my /home on a separate partition and I do disk images of the rest of the file system so I can restore to a known good state when the software demons possess my PC. Clonezilla is your friend.

Thanks, I will look into Clonezilla and see if it helps me. Though I thought that using a daily build of kdenlive means that all dependencies are self-contained within the downloaded folder?

Here is the dpkg -s for libjack-jackd2.0 - do I need libjack0 & libjack-dev as well, do you think?

Package: libjack-jackd2-0
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 525
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Multi-Arch: same
Source: jackd2
Version: 1.9.10+20140719git3eb0ae6a~dfsg-2
Replaces: libjack-0.116
Provides: libjack-0.116
Depends: libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libsamplerate0 (>= 0.1.7), libstdc++6 (>= 4.6)
Pre-Depends: multiarch-support
Suggests: jackd2 (= 1.9.10+20140719git3eb0ae6a~dfsg-2)
Conflicts: jackd2 (>> 1.9.10+20140719git3eb0ae6a~dfsg-2), jackd2 (<< 1.9.10+20140719git3eb0ae6a~dfsg-2), libjack-0.116, libjack0

It is plausible to have thumbnails making app to crash: as it is a multithread process, depending on CPU and Kernel we can trigger different lockup situations (using a low end machine, I already had to rely on reports from people running big i7 systems for this kind of problem).
It would be valuable to get a backtrace of the crash: if it not automatically spit by the crash dialog, then you will have to launch

Code: Select all

shell> gdb kdenlive
gdb> run
[crash]
gdb> bt
gdb> quit


will this gdb command still work with a daily build? it opens up the sunab-installed kdenlive in usr/bin rather than the build in kdenlive/daily/kdenlive which I have been using.

ah yes, you first have to source the script to load environment

Code: Select all

. kdenlive/daily/kdenlive

then re-run gdb pointing on right binary (something like this?)

Code: Select all

gdb kdenlive/daily/bin/kdenlive

Sorry, I don't really understand the first instruction - 'source the script to load environment'. Can you please explain this?
Do you mean /home/sam/kdenlive/daily/kdenlive/bin/kdenlive_env?
I also have the kdenlive binary in that same folder (/home/sam/kdenlive/daily/kdenlive/bin)

I believe you have a sh script in /home/sam/kdenlive/daily/kdenlive that sets LD_LIBRARY_PATH & others to point to the right libraries, MLT data files etc.
If you just run the binary in /home/sam/kdenlive/daily/kdenlive/bin it won't point to the right libraries

Ah, I think I understand now. I have edited this part of the file (/home/sam/kdenlive/daily/kdenlive/start-kdenlive), and it is now writing to a file in /tmp:

# Found gdb, ask for way to run it
WAY_TO_RUN=`kdialog --combobox "<html><p><b>Starting kdenlive from $INSTALL_DIR</b></p><p>Kdenlive can be started in two different ways, please select the way you wish to use.</p><p><b>Normal</b> Normal mode, for normal use</p><p><b>GDB output capture</b> Capture output from kdenlive in the Gnu Debugger in a format suitable for a crash report. Use when trying to isolate a bug</p><p>If in doubt, just click the Ok button.</p></html>" "Normal" "GDB output capture"`
if test 0 != $? ; then
# User clicked cancel
exit
fi
else
WAY_TO_RUN="GDB output capture"

After a few more crashes should I submit a bug report with the output?

Bug report with 3 outputs from GDB.

I see Kdenlive lauching >60 threads, much more than on my laptop

All crashes happen when allocating memory in MLT function:
calloc from mlt_properties_init from mlt_frame_init from producer_get_frame from producer_get_frame from mlt_service_get_frame

Aren't you running out of memory after 5min editing? (maybe you need to activate a system load monitor)

I monitored the memory over the last couple of crashes and the maximum memory reached for kdenlive is about 1.1 GB before it crashes. There's 7.5GB RAM available.


I don't really know much about RAM, performance etc though - is this something I need to fix?
what terms should I search for online in order to find a solution?

Hello,
Sorry for silence; are you still stuck?
I've been looking again at you crash logs (pastebin), they end with:
#1 Fatal IO error 9 (Bad file descriptor)
#2 Fatal IO error 11 (Resource temporarily unavailable)
Maybe you have data stored on an unreliable disk?

hmm, yes I have moved the footage to another drive and initial testing seems a lot better - thanks for the tip! I will keep an eye on any error messages in my logs from now on and see if the problem is solved.