View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003250KdenliveMLTpublic2014-03-31 00:462014-08-05 23:54
Assigned Toj-b-m 
Platformkubuntu 64 bitOSKubuntuOS Version13.10 saucy
Product VersionRecent git 
Target VersionFixed in Version0.9.8 
Summary0003250: Support for MLT threads > 1 is broken (with patch: very jerky) after OpenGL integration
DescriptionI am using the sunab PPA.

Since a recent update of kdenlive (I think the version from 15-03-2014), kdenlive crashes always when trying to add a clip to the project or opening an existing project.

This did not happen with the previous version, I could still use kdenlive on 12-03-2014 without problems.

Below a gdb backtrace and attached the KDE crash report. Please let me know if I can help testing or debugging.
Steps To Reproduce1. Start kdenlive
2. Drag a clip into the project or add it using "Add file"
=> Crash


1. Open an existing project by clicking on it or by using "File -> Open"
=> Crash
Additional InformationProgram received signal SIGSEGV, Segmentation fault.
QGLWidget::makeCurrent (this=0x0) at qgl.cpp:4034
4034 qgl.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) backtrace
#0 QGLWidget::makeCurrent (this=0x0) at qgl.cpp:4034
#1 0x00000000006ecd45 in Render::consumer_thread_stopped (self=0x1c8c470)
    at /build/buildd/kdenlive-0.9.7+git20140315.937f547e/src/renderer.cpp:106
0000002 0x00007ffff48fdc8d in mlt_events_fire (self=self@entry=0x293aec0,
    id=id@entry=0x7ffff490dbd7 "consumer-thread-stopped") at mlt_events.c:219
0000003 0x00007ffff4907012 in consumer_work_stop (self=0x293aec0) at mlt_consumer.c:1281
0000004 mlt_consumer_stop (self=0x293aec0) at mlt_consumer.c:1600
0000005 0x00007ffff46d7841 in Mlt::Consumer::stop() () from /usr/lib/
0000006 0x0000000000702d2f in Render::setProducer (this=0x1c8c470, producer=0x0,
    at /build/buildd/kdenlive-0.9.7+git20140315.937f547e/src/renderer.cpp:1218
0000007 0x0000000000694bd0 in Monitor::slotSetClipProducer (this=0x1ad4ee0, clip=0x3b69550,
    zone=..., forceUpdate=<optimised out>, position=0)
    at /build/buildd/kdenlive-0.9.7+git20140315.937f547e/src/monitor.cpp:869
0000008 0x0000000000695800 in Monitor::qt_static_metacall (_o=0x1ad4ee0, _id=10524352,
    _a=0xa096d0, _c=<optimised out>)
    at /build/buildd/kdenlive-0.9.7+git20140315.937f547e/build/src/monitor.moc:275
0000009 0x00007ffff4ca5a58 in QMetaObject::activate (sender=sender@entry=0x1baae10,
    m=m@entry=0x79cd00 <ProjectList::staticMetaObject>,
    local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fffffffc0a0)
    at kernel/qobject.cpp:3539
0000010 0x00000000006ad540 in ProjectList::clipSelected (this=this@entry=0x1baae10,
    _t1=0x3b69550, _t2=..., _t3=_t3@entry=false)
    at /build/buildd/kdenlive-0.9.7+git20140315.937f547e/build/src/projectlist.moc:600
TagsNo tags attached.
Build/Install Method(select)
Attached Filestxt file icon kdenlive-20140331-004136.kcrash.txt [^] (9,380 bytes) 2014-03-31 00:46 [Show Content]
diff file icon kdenlive-stop-thread-crash.diff [^] (1,005 bytes) 2014-03-31 02:26 [Show Content]

- Relationships

-  Notes
Sesse (developer)
2014-03-31 01:25

This is interesting. It seems one out of two happened: Either you got a NULL QGLWidget when the consumer thread started, or consumer_thread_stopped() was called without consumer_thread_started() ever having called.

The former _should_ be impossible, so my bet would be on the second; it seems that for the read-ahead thread, the logic is water-proof, but that for some other kind of worker threads (whose mission I don't fully understand), consumer-thread-started only gets called once the first frame actually arrives.

I wonder if this is related to MLT's worker thread stuff. Do you think you could go into Settings -> Configure Kdenlive -> Environment and check that “Processing threads“ is at 1? I'm not sure how well anything else will work right now.
dode (reporter)
2014-03-31 01:40

I'm impressed by your analysis - "Processing threads" was at 2 and after setting it to 1 and restarting kdenlive the issue is solved.

So my bad, it says "(> 1 is experimental)", don't even remember why I set it to 2, just trying it out I guess, and since until now there was no problem, I forgot all about it.

Sesse (developer)
2014-03-31 01:56

It seems like the included patch stops it from crashing (although not always?). It's still not a good user experience, though; adding more threads makes this very choppy.

I'm not sure what people want to do about this, and I don't know how mature MLT's support for multiple worker threads actually is in the end. Maybe the best thing to do would be to remove it, but I'm not in a position to know if it's a good idea or not. Keeping it open for now.
vpinon (administrator)
2014-08-05 15:21

- multithreaded rendering has been disabled as it caused much trouble without bringing much apparently
- movit development has been moved to a side branch and will come back in a different for, but your remark can be useful so I keep it in mind, thanks!

- Issue History
Date Modified Username Field Change
2014-03-31 00:46 dode New Issue
2014-03-31 00:46 dode File Added: kdenlive-20140331-004136.kcrash.txt
2014-03-31 01:25 Sesse Note Added: 0009842
2014-03-31 01:40 dode Note Added: 0009843
2014-03-31 01:55 Sesse Category File Loading => MLT
2014-03-31 01:56 Sesse Note Added: 0009844
2014-03-31 01:57 Sesse Priority normal => low
2014-03-31 01:57 Sesse Summary Crash when adding clip to project or opening existing project => Support for MLT threads > 1 is broken (with patch: very jerky) after OpenGL integration
2014-03-31 02:26 Sesse File Added: kdenlive-stop-thread-crash.diff
2014-08-05 15:21 vpinon Note Added: 0010171
2014-08-05 15:21 vpinon Assigned To => vpinon
2014-08-05 15:21 vpinon Status new => acknowledged
2014-08-05 23:54 vpinon Status acknowledged => resolved
2014-08-05 23:54 vpinon Fixed in Version => 0.9.8
2014-08-05 23:54 vpinon Resolution open => fixed
2014-08-05 23:54 vpinon Assigned To vpinon => j-b-m

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker