0001967: melt crash after rendering

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001967

Kdenlive

MLT

public

2011-01-06 00:49

2011-08-04 22:56

Reporter

mcfrisk

Assigned To

j-b-m

Priority

normal

Severity

crash

Reproducibility

always

Status

feedback

Resolution

open

Platform

x86

Debian GNU/Linux

OS Version

unstable

Product Version

Recent git

Target Version

Fixed in Version

Summary

0001967: melt crash after rendering

Description

Melt crashes at the end of rendering to some vdpau problem. PC is a Thinkpad T60 with Intel GPU. This might be a bug somewhere in ffmpeg or vdpau, in which case I hopefully can get rid of it by just removing all vdpau packages.

ffmpeg, mlt and kdenlive are latest from git, few hours old.

Additional Information

$ gdb melt
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 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 "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>... [^]
Reading symbols from /usr/bin/melt...Reading symbols from /usr/lib/debug/usr/bin/melt...done.
done.
(gdb) r syöte_testi01.kdenlive -profile atsc_720p_30 -consumer avformat:/home/mcfrisk/video/20101226_iso-syöte/testi01.mp4 progress=1 f=mp4 acodec=aac ab=128k ar=44100 vcodec=libx264 minrate=0 b=5000k g=250 bf=3 s=1280x720 aspect=@16/9 mbd=2 trellis=1 mv4=1 subq=7 qmin=10 qcomp=0.6 qdiff=4 qmax=51
Starting program: /usr/bin/melt syöte_testi01.kdenlive -profile atsc_720p_30 -consumer avformat:/home/mcfrisk/video/20101226_iso-syöte/testi01.mp4 progress=1 f=mp4 acodec=aac ab=128k ar=44100 vcodec=libx264 minrate=0 b=5000k g=250 bf=3 s=1280x720 aspect=@16/9 mbd=2 trellis=1 mv4=1 subq=7 qmin=10 qcomp=0.6 qdiff=4 qmax=51
[Thread debugging using libthread_db enabled]
[New Thread 0xb493eb70 (LWP 16714)]
[New Thread 0xb26c8b70 (LWP 16715)]
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Xlib: extension "NV-GLX" missing on display ":0.0".
Current Frame: 3934, percentage: 99
[Thread 0xb493eb70 (LWP 16714) exited]
[Thread 0xb26c8b70 (LWP 16715) exited]

Program received signal SIGSEGV, Segmentation fault.
0xa1dfbda8 in ?? () from /usr/lib/libvdpau_nvidia.so
(gdb) thread apply bt full
(gdb) info threads
* 1 Thread 0xb7e436c0 (LWP 16711) 0xa1dfbda8 in ?? ()
   from /usr/lib/libvdpau_nvidia.so
(gdb) bt full
#0 0xa1dfbda8 in ?? () from /usr/lib/libvdpau_nvidia.so
No symbol table info available.
#1 0xb7ff1156 in _dl_fini () at dl-fini.c:248
        nloaded = <value optimized out>
        i = 45
        l = 0x8b24c80
        ns = 0
        maps = <value optimized out>
        maps_size = 103
        do_audit = 0
        __PRETTY_FUNCTION__ = "_dl_fini"
0000002 0xb7e772bf in __run_exit_handlers (status=0, listp=0xb7f8a304,
    run_list_atexit=true) at exit.c:78
        atfct = <value optimized out>
        onfct = <value optimized out>
        cxafct = 0
0000003 0xb7e7732f in exit (status=0) at exit.c:100
No locals.
0000004 0xb7e5ec7e in __libc_start_main (main=0x804a080 <main>, argc=26,
    ubp_av=0xbfffee84, init=0x804b780 <__libc_csu_init>,
    fini=0x804b770 <__libc_csu_fini>, rtld_fini=0xb7ff0f70 <_dl_fini>,
    stack_end=0xbfffee7c) at libc-start.c:260
        result = 0
---Type <return> to continue, or q <return> to quit---
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1208442892, 0, 0,
                -1073746344, 496650822, 697957462}, mask_was_saved = 0}},
          priv = {pad = {0x0, 0x0, 0x1a, 0x80497f0}, data = {prev = 0x0,
              cleanup = 0x0, canceltype = 26}}}
        not_first_call = <value optimized out>
0000005 0x08049811 in _start ()
No symbol table info available.
(gdb)

Tags

No tags attached.

Build/Install Method

Manual build from SVN

Attached Files

Relationships

Notes
(0006301) ttill (developer) 2011-01-07 12:53	Kdenlive shouldn't use VDPAU when rendering.

(0006302) j-b-m (administrator) 2011-01-07 13:24	Strange, since we set the environment variable "MLT_NO_VDPAU" to 1 before starting the render process, MLT should not make use of VDPAU... I don't have VDPAU to test myself, but would be nice if someone can make sure that the "MLT_NO_VDPAU" effectively disables VDPAU for MLT...

(0006399) ddennedy (developer) 2011-02-08 09:18	The reporter is manually running melt within gdb so it is not receiving the signal to not use VDPAU. Should be: MLT_NO_VDPAU=1 gdb melt Besides, on an Intel GPU, the VDPAU will get invoked, and this backtrace leading that way might be due to memory corruption.

(0007136) hirsch (reporter) 2011-08-04 08:58	Same behaviour with me (segfault at 99% irrespectively of the project contents); however, the segfault is in a different place (should I open a different bug?). The packages are taken from debian testing (=unstable), debian version 1:0.7.4-0.1. (gdb) r /sda5/var/tmp/kde-hirsch/kdenliveH11221.mlt -profile hdv_720_30p -consumer avformat:/sda5/kdenlive/khibinyfull.mp4 progress=1 f=mp4 acodec=libmp3lame ab=128k ar=44100 vcodec=mpeg4 minrate=0 b=2000k aspect=@16/9 mbd=2 trellis=1 mv4=1 pass=1 threads=1 real_time=-1 Starting program: /usr/bin/melt /sda5/var/tmp/kde-hirsch/kdenliveH11221.mlt -profile hdv_720_30p -consumer avformat:/sda5/kdenlive/khibinyfull.mp4 progress=1 f=mp4 acodec=libmp3lame ab=128k ar=44100 vcodec=mpeg4 minrate=0 b=2000k aspect=@16/9 mbd=2 trellis=1 mv4=1 pass=1 threads=1 real_time=-1 [Thread debugging using libthread_db enabled] [New Thread 0xb1e80b70 (LWP 8181)] [New Thread 0xb10adb70 (LWP 8182)] Current Frame: 27902, percentage: 99 [Thread 0xb10adb70 (LWP 8182) exited] [Thread 0xb1e80b70 (LWP 8181) exited] Program received signal SIGSEGV, Segmentation fault. 0xb66b5fea in QVariantAnimation::registerInterpolator(QVariant ()(void const, void const*, double), int) () from /usr/lib/libQtCore.so.4

(0007137) hirsch (reporter) 2011-08-04 12:49	Current version from deb http://ppa.launchpad.net/sunab/kdenlive-svn/ubuntu [^] natty main crashed as well :-(

(0007138) ddennedy (developer) 2011-08-04 19:45	hirsch, your bug with a segfault in QVariantAnimation is a known bug in Qt, and it is far from obvious how MLT is triggering it in order to workaround it. More information is in the mlt-devel mailing list by searching on QVariantAnimation. This is fixed for the next Qt release 4.7.4: https://bugreports.qt.nokia.com//browse/QTBUG-16855 [^] This crash appears at the time of process exit, so you should find that the output file is OK. Is it?

(0007139) hirsch (reporter) 2011-08-04 22:30	The output file seems to be OK, but I am not sure if it is the result of the first or of the second pass in the case of two-pass rendering. Both the output file and "...2pass_log" are left. I will try the next Qt, thanks.

(0007140) ddennedy (developer) 2011-08-04 22:56	Kdenlive will not run the second pass if the first pass exits with a failure.

Issue History
Date Modified	Username	Field	Change
2011-01-06 00:49	mcfrisk	New Issue
2011-01-07 12:53	ttill	Note Added: 0006301
2011-01-07 13:24	j-b-m	Note Added: 0006302
2011-01-07 13:24	j-b-m	Assigned To	=> j-b-m
2011-01-07 13:24	j-b-m	Status	new => feedback
2011-02-08 09:18	ddennedy	Note Added: 0006399
2011-08-04 08:58	hirsch	Note Added: 0007136
2011-08-04 12:49	hirsch	Note Added: 0007137
2011-08-04 19:45	ddennedy	Note Added: 0007138
2011-08-04 22:30	hirsch	Note Added: 0007139
2011-08-04 22:56	ddennedy	Note Added: 0007140