Created attachment 104385 [details] backtrace I quite often run into a crash that involves a Clip:Clone in the backtrace, and causes a double free error inside mlt's XML module. The backtrace is similar to the one obtained in https://bugs.kde.org/show_bug.cgi?id=366666 There seems to be several ways to trigger this bug. Loading a project (even a new one) is one way, but the crash happen only ~20% of the time (a double free doesn't necessarily trigger a crash, it would be worth it to look at memory error) An other way, but still inconsistent (it crashes ~30% of the time for me), is to create a new project, add 10+ bin clips, select them all, and add them to the timeline. For me, the "silhouette" of the clips appears, but when releasing the mouse, it crashes. Note that if it doesn't crash the first time, undoing until reacing the empty project and then redoing might help triggering the crash. I'm attaching a backtrace obtained while inserting multiple clips, undoing twice and redoing twice.
I just tried following your steps, adding 16 clips to timeline, did undo/redo cycle for 20 times without crash. Tried the whole thing twice, so either I am very lucky or there must be some other factors. What kind of clips are you adding ? Simple video clips or xml playlist clips ? And what is the profile of your project, and the one of the clips you add ?
I'm adding normal clips, with video of this type: " Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 35459 kb/s, 29.97 fps, 29.97 tbr, 180k tbn, 59.94 tbc (default) " The default profile of the project is Full HD 1080, 30 fps. Compiling the project and melt with -fsanitize=address gives this backtrace: ================================================================= ==29505==ERROR: AddressSanitizer: attempting double-free on 0x602000141c10 in thread T57 (Thread (pooled)): #0 0x7fc4984ceae0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:45 #1 0x7fc458748be4 in on_start_profile /home/nicolas/Documents/Developpement/Projets/mlt/src/modules/xml/producer_xml.c:348 #2 0x7fc458748be4 in on_start_element /home/nicolas/Documents/Developpement/Projets/mlt/src/modules/xml/producer_xml.c:1244 #3 0x7fc4864f17bd in xmlParseStartTag (/usr/lib/libxml2.so.2+0x427bd) #4 0x7fc4864fd1f7 in xmlParseElement (/usr/lib/libxml2.so.2+0x4e1f7) #5 0x7fc4864fc67e in xmlParseContent (/usr/lib/libxml2.so.2+0x4d67e) #6 0x7fc4864fd062 in xmlParseElement (/usr/lib/libxml2.so.2+0x4e062) #7 0x7fc4864fd76a in xmlParseDocument (/usr/lib/libxml2.so.2+0x4e76a) #8 0x7fc45874e7fe in producer_xml_init /home/nicolas/Documents/Developpement/Projets/mlt/src/modules/xml/producer_xml.c:1767 #9 0x7fc4971265a2 in mlt_repository_create /home/nicolas/Documents/Developpement/Projets/mlt/src/framework/mlt_repository.c:238 #10 0x7fc49712568c in mlt_factory_producer /home/nicolas/Documents/Developpement/Projets/mlt/src/framework/mlt_factory.c:315 #11 0x7fc496ecffce in Mlt::Producer::Producer(Mlt::Profile&, char const*, char const*) /home/nicolas/Documents/Developpement/Projets/mlt/src/mlt++/MltProducer.cpp:39 #12 0x6532a3 in Clip::clone() /home/nicolas/Documents/Developpement/Projets/kdenlive/src/timeline/clip.cpp:189 #13 0xd3905e in ProjectClip::thumbProducer() /home/nicolas/Documents/Developpement/Projets/kdenlive/src/bin/projectclip.cpp:421 #14 0xd415eb in ProjectClip::doExtractImage() /home/nicolas/Documents/Developpement/Projets/kdenlive/src/bin/projectclip.cpp:939 #15 0xd50963 in QtConcurrent::VoidStoredMemberFunctionPointerCall0<void, ProjectClip>::runFunctor() /usr/include/qt/QtConcurrent/qtconcurrentstoredfunctioncall.h:205 #16 0x576ac2 in QtConcurrent::RunFunctionTask<void>::run() /usr/include/qt/QtConcurrent/qtconcurrentrunbase.h:136 #17 0x7fc48ce32f8e (/usr/lib/libQt5Core.so.5+0xa8f8e) #18 0x7fc48ce36cf7 (/usr/lib/libQt5Core.so.5+0xaccf7) #19 0x7fc48bd2b453 in start_thread (/usr/lib/../lib/libpthread.so.0+0x7453) #20 0x7fc48c2317de in __GI___clone (/usr/lib/libc.so.6+0xe87de) 0x602000141c10 is located 0 bytes inside of 16-byte region [0x602000141c10,0x602000141c20) freed by thread T30 (Thread (pooled)) here: #0 0x7fc4984ceae0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:45 #1 0x7fc458748be4 in on_start_profile /home/nicolas/Documents/Developpement/Projets/mlt/src/modules/xml/producer_xml.c:348 #2 0x7fc458748be4 in on_start_element /home/nicolas/Documents/Developpement/Projets/mlt/src/modules/xml/producer_xml.c:1244 previously allocated by thread T59 (Thread (pooled)) here: #0 0x7fc4984cee40 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:62 #1 0x7fc48c1c9189 in __GI___strdup (/usr/lib/libc.so.6+0x80189) Thread T57 (Thread (pooled)) created by T0 here: #0 0x7fc498439468 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cc:236 #1 0x7fc48ce361e5 in QThread::start(QThread::Priority) (/usr/lib/libQt5Core.so.5+0xac1e5) Thread T30 (Thread (pooled)) created by T0 here: #0 0x7fc498439468 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cc:236 #1 0x7fc48ce361e5 in QThread::start(QThread::Priority) (/usr/lib/libQt5Core.so.5+0xac1e5) Thread T59 (Thread (pooled)) created by T0 here: #0 0x7fc498439468 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cc:236 #1 0x7fc48ce361e5 in QThread::start(QThread::Priority) (/usr/lib/libQt5Core.so.5+0xac1e5) SUMMARY: AddressSanitizer: double-free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:45 in __interceptor_free ==29505==ABORTING
Ok, I can reproduce now. In fact I was trying with 16.12 where the crash did not happen for me. Looking into it.
Created attachment 104394 [details] Test of concurrent producer creation
Could it be a race condition related to the Profile object ? It seems that there might be some side effects on the mlt_profile when creating a producer using a xml, is that possible? For example the free(p->description) inside producer_xml.c:348, does that affect the original Profile? That would explain what we are obtaining (and the random nature of the bug, because it depends of the order of the operations) I've attached an attempt to reproduce with a toy Mlt code, but it doesn't trigger the bug so far.
So apparently we can workaround this by avoiding the xml step (which seems to be a good idea anyway). I'm pushing a proposed change to master, so that you can review it and cherry-pick it to 16.12 if it looks good to you.
Git commit 9d9010b017c0e744b8b51f41b58ee4be0ac49d0a by Nicolas Carion. Committed on 06/03/2017 at 01:57. Pushed by alcinos into branch 'master'. Avoid relying on xml to clone a clip. M +7 -2 src/timeline/clip.cpp https://commits.kde.org/kdenlive/9d9010b017c0e744b8b51f41b58ee4be0ac49d0a
Yes, I came up with the same analysis and patch. I backported to 16.12, thanks.
Git commit dc80cd7352e01fd7e4b29aa3953f8f577b702a86 by Jean-Baptiste Mardelle, on behalf of Nicolas Carion. Committed on 06/03/2017 at 07:13. Pushed by mardelle into branch 'Applications/16.12'. Avoid relying on xml to clone a clip. M +9 -3 src/timeline/clip.cpp https://commits.kde.org/kdenlive/dc80cd7352e01fd7e4b29aa3953f8f577b702a86
I couldn't figure out from the documentation if properties.inherit(other) also copies the filtler ? Otherwise we need to manually copy all the filters, don't we ?
Git commit 5f6cc24d62edc7a0ceec087a35d4c26315e6569e by Nicolas Carion. Committed on 06/03/2017 at 11:44. Pushed by alcinos into branch 'master'. Avoid relying on xml to clone a clip in BinController M +6 -2 src/mltcontroller/bincontroller.cpp https://commits.kde.org/kdenlive/5f6cc24d62edc7a0ceec087a35d4c26315e6569e
properties.inherit does not copy the filters. However, trying to copy the filters on the clips copied with properties.inherit caused various corruptions and crashes for example on clip reload. My guess is that properties.inherit also copies some internal parameters that should not be duplicated between clips. Since all this was really last minute for 16.12, I opted for a different workaround that I hope will not reveal worse. Based on the conclusion that the producer xml was messing the master profile when parsing a <profile> tag in the xml, in the clone() method, I manually removed the "profile" tag, avoiding the threading / corruption problem. I think the xml producer should allow creating an MLT producer without messing the project profile, so in my opinion, something is wrong in MLT. Don't you think ? I will think a little more about it and ask on MLT's list what they think about it.
For the Mlt problem, I've already opened an issue: https://github.com/mltframework/mlt/issues/212 Your workaround seems good enough for now, but we must make sure that there is no other way to trigger race conditions. The XML parsing seems a bit clanky overall on MLT's side… Anyway, I'd advocate for a non XML solution in the long run. One benefit is speed, I experienced a decent speed-up with the temporary solution without XML
It seems that this report is related to a very old unmaintained version. A lot changed since then and it is likely that this has been fixed. Feel free to reopen this bug or create a new report if this is still happening with the latest version (https://kdenlive.org/en/download/)