The most bizarre thing in all this is that kdenlive_renderer doesn't crash if I run it from shell.

I use "ps xuwa" to extract the full command line of kdenlive_renderer immediately after beginning export from KDEnlive before renderer crashes.

I also make a copy of the temporary kdenliveXXXXXX.westley file that's placed in /tmp during export.

Then I run:

kdenlive_renderer kdenliveI9D3ha.westley real_time=0 resize=hyper in=0 out=1036 -consumer avformat test1.vob real_time=0 stats_on=1 qscale=0 aspect_ratio=1.06667 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 ildct=1 ilme=1 profile=dv > test1_out.vob

The result is a rendered DVD-quality VOB in test1_out.vob. The crossfade is rendered successfully and there's no crash.

Maybe something in the environment confuses kdenlive_renderer when it's run from KDEnlive?

Are you sure that you know which kdenlive_renderer is called by kdenlive you have just tested?

Check my bugreport about kdenlive_renderer search path.

Have you set PATH=.:$PATH enabling Kdenlive to preferably pick kdenlive_renderer from the same directory as is kdenlive itself?

??

What is you directory structure of kdenlive and its subproject? They are in separate directories aren't they?

kdenlive_builder suppose this structure:

/kdenlive
/ffmpeg
/mlt
/mlt++

OK, but you will miss some Kdenlive capacities. You will not be able to edit movies with mp3 audio codec for example and many more.

Please, post any problems, alterations, recommendations, etc to this separate thread:

viewtopic.php?f=8&t=68

Thank you

The system-wide installed in /usr, build from SVN - there's currently no other, since in this case the point was to make it crash. And it didn't.

I had a problem exporting to Mpeg2. On the first transition, the export stops. I added qscale=1 and it succeeded.

I've tried building MLT and KDEnlive with all the debug symbols, and linked with Electric Fence (http://en.wikipedia.org/wiki/Electric_Fence) in order to catch where exactly does it crash.

The build is performed using a modified version of espinosa_cz's build script (see attachment).

I have aproblem, however. Electric Fence detects a zero-size malloc when KDEnlive displays its splash screen on startup. The cause seems to be in QT libraries:

$ gdb bin/kdenlive
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive
[Thread debugging using libthread_db enabled]
[New Thread -1209444656 (LWP 597)]

  Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
Qt: gdb: -nograb added to command-line options.
         Use the -dograb option to enforce grabbing.
X Error: BadDevice, invalid or uninitialized input device 169
  Major opcode:  145
  Minor opcode:  3
  Resource id:  0x0
Failed to open device
X Error: BadDevice, invalid or uninitialized input device 169
  Major opcode:  145
  Minor opcode:  3
  Resource id:  0x0
Failed to open device

ElectricFence Aborting: Allocating 0 bytes, probably a bug.

Program received signal SIGILL, Illegal instruction.
[Switching to Thread -1209444656 (LWP 597)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x45a73226 in kill () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7f12c54 in EF_Abort () from /usr/lib/libefence.so.0
#3  0xb7f1271b in memalign () from /usr/lib/libefence.so.0
#4  0xb7f1288b in malloc () from /usr/lib/libefence.so.0
#5  0x4c4e5b59 in QRegion::clipRectangles (this=0xbf8e1c44, num=@0xbf8e1c0c) at kernel/qregion_x11.cpp:2882
#6  0x4c4e493a in qt_getClipRects (r=@0xbf8e1c44, num=@0xbf8e1c0c) at kernel/qpainter_x11.cpp:140
#7  0x4c4dad9d in x11SetClipRegion (dpy=0xb6f27ac4, gc=0xabebcf90, gc2=0xabed2f90, draw=2883231692, r=@0xbf8e1c44) at kernel/qpainter_x11.cpp:146
#8  0x4c4e227a in QPainter::setClipping (this=0xbf8e1f6c, enable=true) at kernel/qpainter_x11.cpp:1474
#9  0x4c4e2430 in QPainter::setClipRegion (this=0xbf8e1f6c, rgn=@0xbf8e1dc8, m=QPainter::CoordDevice) at kernel/qpainter_x11.cpp:1531
#10 0x4c594712 in qt_format_text (font=@0xbf8e1f8c, _r=@0xbf8e1f2c, tf=134217729, str=@0xabd41ff0, len=14, brect=0x0, tabstops=0, tabarray=0x0, tabarraylen=0,
    painter=0xbf8e1f6c) at kernel/qpainter.cpp:3057
#11 0x4c594988 in QPainter::drawText (this=0xbf8e1f6c, r=@0xbf8e1f2c, tf=1, str=@0xabd41ff0, len=14, brect=0x0, internal=0x0) at kernel/qpainter.cpp:2807
#12 0x4c6c7f86 in QSplashScreen::drawContents (this=0xb2abff88, painter=0xbf8e1f6c) at widgets/qsplashscreen.cpp:265
#13 0x4c6c7ffa in QSplashScreen::drawContents (this=0xb2abff88) at widgets/qsplashscreen.cpp:250
#14 0x4c6c8087 in QSplashScreen::repaint (this=0xb2abff88) at widgets/qsplashscreen.cpp:161
#15 0x4c6c82eb in QSplashScreen::message (this=0xb2abff88, message=@0xbf8e2110, alignment=1, color=@0x4ca631b8) at widgets/qsplashscreen.cpp:191
#16 0x0814b510 in KdenliveSplash (this=0xb2abff88, pixmap=@0xbf8e21e8) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/kdenlive/kdenlivesplash.cpp:23
#17 0x0813986c in KdenliveApp (this=0xb441bc54, newDoc=false, parent=0x0, name=0x0) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/kdenlive/kdenlive.cpp:199
#18 0x08183c55 in main (argc=136472076, argv=0xbf8e2514) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/kdenlive/main.cpp:94
(gdb)

Anyone tried debugging KDE apps with Electric Fence? Do they always bomb out prematurely because of some non harmful allocation error in QT? What to try instead of Electric Fence, then?

After trying to debug using Valgrind (too slow for me and lots of unrelated errors I didn't have time to sift through :( ), I've got back to fiddling with paths and linking.

I've discovered that indeed kdenlive renderer was using the system-wide version of mlt, and as a result the system-wide libavformat.

It was also posssible that kdenlive_renderer was called from /usr/bin, not your script's build directory.

So I've written a shell script that initialies environment accordingly before it launches kdenlive:

#!/bin/sh
export PATH="/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:$PATH"
export LD_LIBRARY_PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib
/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive

Now I've verified that it launches proper kdenlive_renderer and that renderer loads the proper libraries:

$ export PATH="/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:$PATH"
$ export LD_LIBRARY_PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib
$ cd /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa
$ ldd build/share/mlt/modules/libmltavformat.so
        linux-gate.so.1 =>  (0xffffe000)
        libavformat.so.51 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavformat.so.51 (0xb7eaf000)
        libavcodec.so.51 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 (0xb7a8c000)
        libavutil.so.49 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavutil.so.49 (0xb7a82000)
        libmlt.so.0.2.3 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libmlt.so.0.2.3 (0xb7a5f000)
        libswscale.so.0 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libswscale.so.0 (0xb7a38000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb78d7000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb78c3000)
        libogg.so.0 => /usr/lib/libogg.so.0 (0xb78be000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb78ba000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb77c9000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb77bb000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7793000)
        liba52-0.7.4.so => /usr/lib/liba52-0.7.4.so (0xb7788000)
        libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0xb76ce000)
        libtheora.so.0 => /usr/lib/libtheora.so.0 (0xb7695000)
        libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb766d000)
        libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb7571000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7559000)
        /lib/ld-linux.so.2 (0x80000000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7556000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7551000)
$ ldd build/bin/kdenlive_renderer 
        linux-gate.so.1 =>  (0xffffe000)
        libmlt.so.0.2.3 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libmlt.so.0.2.3 (0xb7f8a000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x45a49000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x45b92000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x45b8c000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x45bbb000)
        /lib/ld-linux.so.2 (0x4507a000)

After running kdenlive and launching timeline export to DVD format, I quickly check that it launches the proper kdenlive_renderer binary:

$ ps xuwa | grep kdenlive
olo      13883  0.0  0.0   1716   464 pts/4    S+   10:14   0:00 /bin/sh ./kdenlive.sh
olo      13884 16.2  4.3 106128 44756 pts/4    Sl+  10:14   0:18 /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive
olo      14009  136  1.7  40880 18640 pts/4    Rl+  10:16   0:01 kdenlive_renderer /tmp/kde-olo/kdenlivesqyfYa.westley real_time=0 resize=hyper in=0 out=234 -consumer avformat /home/olo/Test5.vob real_time=0 stats_on=1 qscale=0 aspect_ratio=1.06667 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 ildct=1 ilme=1
olo      14012  0.0  0.0   2888   748 pts/7    R+   10:16   0:00 grep kdenlive
olo@stacja:~$ ls -l /proc/14009/exe
lrwxrwxrwx 1 olo olo 0 2007-06-29 10:16 /proc/14009/exe -> /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive_renderer

So now everything should be fine, right? But it still crashes when reaches the transition.

Here's the gdb backtrace, as can be seen, the version of libavcodec that was built from SVN by your script is involved (/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51):

Core was generated by `kdenlive_renderer /tmp/kde-olo/kdenlive53d5Fb.westley real_time=0 resize=hyper'.
Program terminated with signal 6, Aborted.
#0  0xffffe410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 2 (process 14909):
#0  0xb7f2b768 in generate_hash (name=0xb7f3d834 "ition") at mlt_properties.c:162
#1  0xb7f2b812 in mlt_properties_find (this=0x80790d8, name=0xb7f3d830 "_position") at mlt_properties.c:277
#2  0xb7f2c3f1 in mlt_properties_get_position (this=0x80790d8, name=0xb7f3d830 "_position") at mlt_properties.c:662
#3  0xb7f2fe34 in mlt_producer_position (this=0x80790d8) at mlt_producer.c:274
#4  0x08048bcc in transport (producer=0x80790d8, consumer=0x80839a0) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/renderer/kdenlive_renderer.c:43
#5  0x08048fb4 in main (argc=31, argv=0xbfb0e3b4) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/renderer/kdenlive_renderer.c:147

Thread 1 (process 14910):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x45a72df0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x45a74641 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7b55b13 in ff_rate_estimate_qscale () from /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51
#5  0x08249e40 in ?? ()
#6  0x0824d0d0 in ?? ()
#7  0x45b85ff4 in ?? () from /lib/tls/i686/cmov/libc.so.6
#8  0x00000000 in ?? ()
(gdb)

But when I run the same kdenlive_renderer job with the same arguments (extracted from /proc/PID/) from command line, it finishes its job successfully!

The environments of the kdenlive-launched job and manually-launched job are nearly identical - here's the diff between them:

--- 2007-06-29_10_53_19.environ.txt     2007-06-29 11:03:46.000000000 +0200
+++ 2007-06-29_11_03_09.environ.txt     2007-06-29 11:03:53.000000000 +0200
@@ -15,20 +15,21 @@
 LC_MONETARY=pl_PL.UTF-8
 DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-fAUHgn0pLo,guid=fcc33edf9f66cd436b0806004684b240
 LOGNAME=olo
-_=./kdenlive.sh
+_=/bin/sh
 WINDOWID=50331676
 XTERM_SHELL=/bin/bash
 TERM=screen
 LC_COLLATE=pl_PL.UTF-8
 GTK2_RC_FILES=/home/olo/.gtkrc-2.0-kde
 SESSION_MANAGER=local/stacja.amarczuk:/tmp/.ICE-unix/11372
-PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/NX/bin:~/bin
+PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/NX/bin:~/bin
 XCURSOR_THEME=kubuntu
 LC_ADDRESS=pl_PL.UTF-8
 DISPLAY=:0.0
 LANG=en_US.UTF-8
 STY=13247.pts-3.stacja
 LC_TELEPHONE=pl_PL.UTF-8
+DESKTOP_STARTUP_ID=stacja.amarczuk;1183102586;143712;11375_TIME1233040
 LC_MESSAGES=pl_PL.UTF-8
 SSH_AUTH_SOCK=/tmp/ssh-ifXHT11239/agent.11239
 LC_NAME=pl_PL.UTF-8
@@ -67,6 +68,3 @@
        :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:km:
 LC_NUMERIC=pl_PL.UTF-8
 LC_PAPER=pl_PL.UTF-8
-MLT_NORMALISATION=PAL
-SDL_WINDOWID=67111583
-AUDIODEV=default

I've also tried setting the missing environment options manually then run the manual job:

$ export MLT_NORMALISATION=PAL
$ export AUDIODEV=default
$ export SDL_WINDOWID=67111583
$ export 'DESKTOP_STARTUP_ID=stacja.amarczuk;1183102586;143712;11375_TIME1233040'
$ sh /home/olo/Documents/rsync/repo/QA/KDEnlive/2007-06-29_Export_crash/test_run.sh > ~/Test7_out.vob

BTW, espinosa_cz, would it be possible to link all the libs built by your script statically into the binaries? In order to make sure that no wrong version of FFMPEG or MLT gets linked dynamically by kdenlive or kdenlive_renderer.

jmpoure, could you try the attached scripts to capture a testcase?

First, you have to build KDEnlive using the modified espinosa_script-olo.sh script attached here. Change the DEST_DIR variable in the script to your preferred directory.

Then, modify the the second script, kdenlive-espinosa.sh, (set the build_dir variable to the same value as DEST_DIR in espinosa's script) to launch KDEnlive.

Then take the third script, catch_testcase.sh, set build_dir variable in that script too, then make yourself ready.

In KDEnlive, launch an export of your project, then immediately launch catch_testcase.sh - it will collect some data for a test case (make a copy of your temporary .westley file, all used temporary .PNG files and process the .westley file to use those copies, capture some data about kdenlive_renderer's running environment and generate a script that lets you launch kdenlive_renderer manually).

Then take a look at the generated testcase script - e.g. 2007-06-29_12_38_29_test_run.sh.

If its contents look OK, run it. It should output a .VOB file containing the exported video.

Note if it finishes its work or will it crash. Analyse the other files generated by catch_testcase.sh.

In my case, despite nearly identical environments, kdenlive_renderer doesn't crash and finishes export successfully when run manually, but it crashes when launched by kdenlive.

All scripts are gzipped, otherwise the forum won't let me attach them.

I will try, probably tonight.

I just wanted to add a "me too" to the "export/rendering fails strangely" thread.

Plus a possible fix.

As an example, I create a simple project consisting of two Image clips, one

after the other. Rendering this always crashes before the second clip. (This

is renderig to mpeg or mpeg4, highest resolution and quality).

I did some exploring and found that the rendering is crashing in libavcodec

in ff_rate_estimate_qscale at line 756

assert(q>0.0);

If I comment out that assert and the next one (line 768) but not the last one (line 774).

And then recompile and make sure the new library gets used,

then the rendering works perfectly, at least for that project...

neilbrown, do you mean such changes?

Index: libavcodec/ratecontrol.c
===================================================================
--- libavcodec/ratecontrol.c    (revision 9460)
+++ libavcodec/ratecontrol.c    (working copy)
@@ -749,7 +749,7 @@
         if (q < 0)
             return -1;
 
-        assert(q>0.0);
+//        assert(q>0.0);
 //printf("%f ", q);
         q= get_diff_limited_q(s, rce, q);
 //printf("%f ", q);
@@ -765,7 +765,7 @@
             q= short_term_q= rcc->short_term_qsum/rcc->short_term_qcount;
 //printf("%f ", q);
         }
-        assert(q>0.0);
+//        assert(q>0.0);
 
         q= modify_qscale(s, rce, q, picture_number);

I've rebuilt using this modified FFMPEG, but kdenlive_renderer still crashes (and still in ff_rate_estimate_qscale (), too):

...
#3  0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7babb9e in ff_rate_estimate_qscale () from /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51
...

Maybe I should eliminate all the assertions from this function not only those two?

But they were probably placed there for a purpose.

Could anybody with a deeper knowledge of FFMPEG comment on the role of those assertions?

There are a lot of asserts there, aren't there!

I think the first one that I commented out is different from the first

one in your patch. I suggest if it is still crashing, comment them all out.

I doubt this is really the "right" solution, but for me it works until something

better comes along. I too would like to know what really is going on here...

You were right, now my diff between FFMPEG SVN and working copy looks like this and I don't experience crashes of kdenlive_renderer in this situation:

Index: libavcodec/ratecontrol.c
===================================================================
--- libavcodec/ratecontrol.c    (revision 9460)
+++ libavcodec/ratecontrol.c    (working copy)
@@ -749,11 +749,11 @@
         if (q < 0)
             return -1;
 
-        assert(q>0.0);
+//        assert(q>0.0);
 //printf("%f ", q);
         q= get_diff_limited_q(s, rce, q);
 //printf("%f ", q);
-        assert(q>0.0);
+//        assert(q>0.0);
 
         if(pict_type==P_TYPE || s->intra_only){ //FIXME type dependent blur like in 2-pass
             rcc->short_term_qsum*=a->qblur;
@@ -765,7 +765,7 @@
             q= short_term_q= rcc->short_term_qsum/rcc->short_term_qcount;
 //printf("%f ", q);
         }
-        assert(q>0.0);
+//        assert(q>0.0);
 
         q= modify_qscale(s, rce, q, picture_number);

But it's still intriguing, if those asserts weren't satisfied, then something goes against FFMPEG developers' expectations here. Possibly the rate estimation may work incorrectly. Any ideas how to test that?

I'll also try reducing the number of commented out asserts to determine the minimum count that "fixes" our problem.

Here's the minimal changes that eliminate crashing (2 asserts need to be disabled):

Index: libavcodec/ratecontrol.c
===================================================================
--- libavcodec/ratecontrol.c    (revision 9460)
+++ libavcodec/ratecontrol.c    (working copy)
@@ -753,7 +753,7 @@
 //printf("%f ", q);
         q= get_diff_limited_q(s, rce, q);
 //printf("%f ", q);
-        assert(q>0.0);
+//        assert(q>0.0);
 
         if(pict_type==P_TYPE || s->intra_only){ //FIXME type dependent blur like in 2-pass
             rcc->short_term_qsum*=a->qblur;
@@ -765,7 +765,7 @@
             q= short_term_q= rcc->short_term_qsum/rcc->short_term_qcount;
 //printf("%f ", q);
         }
-        assert(q>0.0);
+//        assert(q>0.0);
 
         q= modify_qscale(s, rce, q, picture_number);
 

Bug

viewtopic.php?f=16&t=117&p=414#p414

fas found as duplicate of yours.