i use a custom rendering profile with the following parameters:

vcodec=libx264 s=1920x1080 preset=slow pix_fmt=yuv420p vlevel=41 refs=4

the rendering goes fine for a minute. then the dialog and main window of KDENLiVE disappear. however MELT and kdenlive_render processes keep working until they produce the output file. that wouldn't be a big deal but i'd like to see the progress.

kdenlive, kdenlive-data and libmlt6 were installed from Olivier Banus's PPA at https://launchpad.net/~sunab/+archive/u ... ve-release

Please run Kdenlive under gdb control, so you can see if Kdenlive crashes and then get a backtrace. Please file then a bug report and attach your report. Please also attach a minimal(!) example project that triggers the crash. Thank you!

Code: Select all

$ sudo apt install kdenlive-dbg=4:15.12.1-0ubuntu0~sunab~xenial1
$ gdb kdenlive
GNU gdb (Ubuntu 7.11-0ubuntu1) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from kdenlive...Reading symbols from /usr/lib/debug//usr/bin/kdenlive...(no debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb)

TheDiveO wrote:Please file then a bug report

You'll find the link to the bug tracking system on the Kdenlive website.

for some reason the problem's gone. i noticed that now CPU usage of the melt process is 60 to 80%, whereas it was above 90% before. i thought it might be because of the debugging symbols, but when i purged them nothing changed.

today the problem got back. i think it's because of my hardware that can't cope with the rendering. i've been meaning to upgrade it anyway.

You might be running out of RAM. Kdenlive does use a hell of a lot of RAM during editing (memory leaks likely the cause) and more is used to render. With recent kernels when RAM is nearly used up the worst memory hogs are killed. Usually this kills Kdenlive, while melt continues running as a zombie. If you kill kdenlive yourself the render jobs continue and finish sucessfully, this might also happen in the out of RAM case but I have not tested that. Last time I had this issue I also had an issue in the project (compositing a track w/o a transition over a transition between two tracks) that crashes render jobs.

Well, I have yet to see a real case where debugging symbols caused a program to crash, unless it was a debugger or tracing tool. I was actually asking to report a stack trace with a bug report, not some arbitrary gdb console output here in the forum. There's a dedicated bug reporting service linked to from the Kdenlive website. If a program crashes under gdb control, the command bt gives a backtrace. This specific output can be of help to developers, but it may not always be so. In your case the reason may not be software but hardware unless you changed something software-wise in the meantime, stripping symbols not counting as changing something.

lukefromdc wrote:If you kill kdenlive yourself the render jobs continue and finish sucessfully

I also face this issue with huge projects with hundreds of clips (memory used to remain allocated for every clip loaded in the project, should be better with recent Kdenlive/MLT).
I personally export as a script, then close kdenlive, then execute the *.mlt.sh.
To avoid running out of memory, you can also increase the swap space (just saving from accidents, everything can become terribly slow when swapping)

lukefromdc wrote:You might be running out of RAM ...

perhaps, although i believe the narrowest bottleneck is CPU in my case. anyway, i'm going to upgrade them both.

TheDiveO wrote:Well, I have yet to see a real case where debugging symbols caused a program to crash, unless it was a debugger or tracing tool. I was actually asking to report a stack trace with a bug report, not some arbitrary gdb console output here in the forum. There's a dedicated bug reporting service linked to from the Kdenlive website. If a program crashes under gdb control, the command bt gives a backtrace ...

doesn't the output "no debugging symbols found" mean that i can't get a backtrace?

vpinon wrote:I also face this issue with huge projects with hundreds of clips (memory used to remain allocated for every clip loaded in the project, should be better with recent Kdenlive/MLT).

and what versions are those?

vpinon wrote:I personally export as a script, then close kdenlive, then execute the *.mlt.sh.

thanks for sharing this.

vpinon wrote:To avoid running out of memory, you can also increase the swap space (just saving from accidents, everything can become terribly slow when swapping)

uhm, i guess the rendering is already slow enough with my hardware, so i'd better get a new one.

humanbeing wrote:

TheDiveO wrote:Well, I have yet to see a real case where debugging symbols caused a program to crash, unless it was a debugger or tracing tool. I was actually asking to report a stack trace with a bug report, not some arbitrary gdb console output here in the forum. There's a dedicated bug reporting service linked to from the Kdenlive website. If a program crashes under gdb control, the command bt gives a backtrace ...

doesn't the output "no debugging symbols found" mean that i can't get a backtrace?

There are still a lot of public symbols left that often already give a good indication. Best is having a minimal project triggering a bug.