Created attachment 140211 [details] Contains project Parent.kdenlive, that child projects, crashes kdenlive. SUMMARY KDEnlive crashes opening a project that consists of nested projects as its clips. Meaning I imported projects as clips into the parent project. I was initially using kdenlive from ubuntu repos. The problem appeared when I edited the child project in a manner that shortened its length after having added it to the timeline of the parent. This caused kdenlive to crash when trying to play the now non-existent section of the child project on the timeline. That was fixable by deleting the clip and re-adding it. It would still occasionally crash, but not always when playing the end of the child project. I switched to the latest kdenlive from the kdenlive.stable PPA, 21.04.3. And now it crashes when just trying to open the parent file. STEPS TO REPRODUCE 1. Open the attached project Parent.kdenlive 2. Use placholders for missing clips 3. Kdenlive crashes OBSERVED RESULT SEGFAULT EXPECTED RESULT No SEGFAULT SOFTWARE/OS VERSIONS Linux Plasma: Ubuntu 20.04.02 LTS Qt Version: 5.12.8 ADDITIONAL INFORMATION The problem also appeared with a self-compiled kdenlive from mastet. The error stack pointed to mltnormalize.so, but when I tried to compile a custom debug mlt and use it, kdenlive crashed on startup (some service instance in mlt was 0x0). That seemed like an entirely different problem likely related to me not getting the self-compiled mlt and kdenlive to match properly, so I couldn't get any useful information down that path. libmltnormalize.so![Unknown/Just-In-Time compiled code] (Unknown Source:0) libmlt.so.6!mlt_frame_get_audio (Unknown Source:0) libmltcore.so![Unknown/Just-In-Time compiled code] (Unknown Source:0) libmlt.so.6!mlt_frame_get_audio (Unknown Source:0) libmltcore.so![Unknown/Just-In-Time compiled code] (Unknown Source:0) libmlt.so.6!mlt_frame_get_audio (Unknown Source:0) libmlt.so.6![Unknown/Just-In-Time compiled code] (Unknown Source:0) libmlt.so.6!mlt_frame_get_audio (Unknown Source:0) libmltnormalize.so![Unknown/Just-In-Time compiled code] (Unknown Source:0) libmlt.so.6!mlt_frame_get_audio (Unknown Source:0) libmlt.so.6![Unknown/Just-In-Time compiled code] (Unknown Source:0) libpthread.so.0!start_thread(void * arg) (/build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477) libc.so.6!clone() (/build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/x86_64/clone.S:95)
Tried also with the 21.04.03 AppImage. Same result. Here is the tail of the command line output: QQmlContext: Cannot set context object on invalid context. QQmlComponent: Cannot create a component in an invalid context QQmlContext: Cannot set context object on invalid context. QQmlComponent: Cannot create a component in an invalid context QQmlContext: Cannot set context object on invalid context. QQmlComponent: Cannot create a component in an invalid context [mp3 @ 0x7fdc69527640] Estimating duration from bitrate, this may be inaccurate [mp3 @ 0x7fdc69548f00] Estimating duration from bitrate, this may be inaccurate [mp3 @ 0x7fdc57a48980] Estimating duration from bitrate, this may be inaccurate [mp3 @ 0x7fdc57a4b5c0] Estimating duration from bitrate, this may be inaccurate [mp3 @ 0x7fdcbfab5b40] Estimating duration from bitrate, this may be inaccurate [mp3 @ 0x7fdcbfacfe80] Estimating duration from bitrate, this may be inaccurate [mp3 @ 0x7fdc09957540] Estimating duration from bitrate, this may be inaccurate [mp3 @ 0x7fdcbf50dc00] Estimating duration from bitrate, this may be inaccurate /tmp/.mount_kdenli9Mwi79/AppRun: line 42: 54415 Segmentation fault (core dumped) kdenlive --config kdenlive-appimagerc $@
Okay, I managed to debug it with a mlt and kdenlive from their masters. (This failed before, because I was missing the libxml dependency for mlt, which caused project loading to crash when the consumer "xml:kdenlive_playlist" didn't initialize properly.) Anyways, in master it only crashed when I tried to actually play the timeline. The crash occurred at libmltavformat.so!producer_get_image(mlt_frame frame, uint8_t ** buffer, mlt_image_format * format, int * width, int * height, int writable) (/home/keski/code/others/mlt/src/modules/avformat/producer_avformat.c:1903), when calling avcodec_send_packet. It crashes inside libavcodec.so, so I am not at the bottom of this yet. The context and pkt given as parameters are not obviously invalid to a layman's eyes. I'll add an attachment with the call stack and info on the parameters that caused the call to avcodec_send_packet to crash.
Created attachment 140233 [details] Call stack and parameters that caused avcodec_send_packet to crash.
Now caught it crashing because self->video_format was NULL when calling avformat_find_stream_info at producer_avformat.c:producer_open. This happened right when opening the project, not trying to play it. Interestingly this is right after an if that checks it is not null, so I suspect it is a concurrency issue of some kind. That would also explain why this doesn't happen every time. libavcodec.so.58![Unknown/Just-In-Time compiled code] (Unknown Source:0) libavcodec.so.58!avcodec_send_packet (Unknown Source:0) libavformat.so.58![Unknown/Just-In-Time compiled code] (Unknown Source:0) libavformat.so.58!avformat_find_stream_info (Unknown Source:0) libmltavformat.so!producer_open(producer_avformat self, mlt_profile profile, const char * URL, int take_lock, int test_open) (/home/keski/code/others/mlt/src/modules/avformat/producer_avformat.c:842) libmltavformat.so!producer_set_up_video(producer_avformat self, mlt_frame frame) (/home/keski/code/others/mlt/src/modules/avformat/producer_avformat.c:2380) libmltavformat.so!producer_get_frame(mlt_producer producer, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/modules/avformat/producer_avformat.c:3096) libmlt-7.so.7!producer_get_frame(mlt_service service, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_producer.c:663) libmlt-7.so.7!mlt_service_get_frame(mlt_service self, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_service.c:581) libmlt-7.so.7!producer_get_frame(mlt_service service, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_producer.c:714) libmlt-7.so.7!mlt_service_get_frame(mlt_service self, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_service.c:581) libmlt-7.so.7!producer_get_frame(mlt_producer producer, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_playlist.c:2066) libmlt-7.so.7!producer_get_frame(mlt_service service, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_producer.c:663) libmlt-7.so.7!mlt_service_get_frame(mlt_service self, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_service.c:581) libmlt-7.so.7!producer_get_frame(mlt_producer parent, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_multitrack.c:612) libmlt-7.so.7!producer_get_frame(mlt_service service, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_producer.c:663) libmlt-7.so.7!mlt_service_get_frame(mlt_service self, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_service.c:581) libmlt-7.so.7!producer_get_frame(mlt_producer parent, mlt_frame_ptr frame, int track) (/home/keski/code/others/mlt/src/framework/mlt_tractor.c:498) libmlt-7.so.7!producer_get_frame(mlt_service service, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_producer.c:663) libmlt-7.so.7!mlt_service_get_frame(mlt_service self, mlt_frame_ptr frame, int index) (/home/keski/code/others/mlt/src/framework/mlt_service.c:581)
I added a debug print that output &self from producer_avformat_close. I was able to catch a situation where the self in producer_open was the same address after it was closed. So somehow the producer is being closed while it is being opened. I suspect the guilty stack is libmltavformat.so!producer_avformat_close(producer_avformat self) (/home/keski/code/others/mlt/src/modules/avformat/producer_avformat.c:3117) libmlt-7.so.7!cache_object_close(mlt_cache cache, void * object, void * data) (/home/keski/code/others/mlt/src/framework/mlt_cache.c:142) libmlt-7.so.7!mlt_cache_item_close(mlt_cache_item item) (/home/keski/code/others/mlt/src/framework/mlt_cache.c:185) libmlt-7.so.7!clear_property(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:113) libmlt-7.so.7!mlt_property_close(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:912) libmlt-7.so.7!mlt_properties_close(mlt_properties self) (/home/keski/code/others/mlt/src/framework/mlt_properties.c:1506) libmlt-7.so.7!mlt_frame_close(mlt_frame self) (/home/keski/code/others/mlt/src/framework/mlt_frame.c:768) libmlt-7.so.7!clear_property(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:113) libmlt-7.so.7!mlt_property_close(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:912) libmlt-7.so.7!mlt_properties_close(mlt_properties self) (/home/keski/code/others/mlt/src/framework/mlt_properties.c:1506) libmlt-7.so.7!mlt_frame_close(mlt_frame self) (/home/keski/code/others/mlt/src/framework/mlt_frame.c:768) libmlt-7.so.7!clear_property(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:113) libmlt-7.so.7!mlt_property_close(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:912) libmlt-7.so.7!mlt_properties_close(mlt_properties self) (/home/keski/code/others/mlt/src/framework/mlt_properties.c:1506) libmlt-7.so.7!mlt_frame_close(mlt_frame self) (/home/keski/code/others/mlt/src/framework/mlt_frame.c:768) libmlt-7.so.7!clear_property(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:113) libmlt-7.so.7!mlt_property_close(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:912) libmlt-7.so.7!mlt_properties_close(mlt_properties self) (/home/keski/code/others/mlt/src/framework/mlt_properties.c:1506) libmlt-7.so.7!mlt_frame_close(mlt_frame self) (/home/keski/code/others/mlt/src/framework/mlt_frame.c:768) libmlt-7.so.7!clear_property(mlt_property self) (/home/keski/code/others/mlt/src/framework/mlt_property.c:113) I don't have the stack of the closing that did it, because I had no way to know in advance which closing was the one whose producer would be used after it. But most closing seemed to be done by the above stack. So somehow the cache item is being destroyed while it is still in use?
I tried to make producer_avformat_close hold the video_mutex, but I of course had to make it conditional on is_mutex_init, and the mutexes are not inited until producer_open, and the sequence of events seems to be. 1. Producer is created and added to the cache. 2. Something else is put to the cache, which causes this producer to be closed with producer_avformat_close. 3. producer_open is called on this producer. So the mutexes are not available yet in the crashing case. As mentioned, this occurs with nested projects. Could the stack of projects be filling the cache such that not all the necessary producers fit in it at the same time, or something? I have little understanding of this code base, that's just what came to mind from the "object is expelled from cache before being created" + "occurs with nested projects". Is the child project a producer? And do it's clips get loaded as new producers during its initialization, such that it could be the one being expelled like this? Can I increase the size of the cache somehow?
Created attachment 140439 [details] Kdenlive_Error message while importing Thank you for reporting. I get some error massage while opening the project with placeholders. Playback with placeholders is working -> no crash.
Hello, thanks for the detailed feedback, are you still able to reproduce this in latest version?
(In reply to farid from comment #8) > Hello, thanks for the detailed feedback, are you still able to reproduce > this in latest version? No. In the latest version there is a pile of "invalid producer found and removed" messages and playing the project displays nothing but "INVALID", but there are no crashes. Whether the true underlying bug has been fixed or the project is just incompatible, I cannot tell, but it sure does not reproduce with the test file I have.
(In reply to Mitten Orvan from comment #9) > (In reply to farid from comment #8) > > Hello, thanks for the detailed feedback, are you still able to reproduce > > this in latest version? > > No. In the latest version there is a pile of "invalid producer found and > removed" messages and playing the project displays nothing but "INVALID", > but there are no crashes. Whether the true underlying bug has been fixed or > the project is just incompatible, I cannot tell, but it sure does not > reproduce with the test file I have. The invalid message is because Kdenlive can't find your footage. Was it on a hard drive?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Could you please test again with the latest AppImage St: https://cdn.kde.org/ci-builds/multimedia/kdenlive/release-24.08/linux/ Build 9034 Thanks for your help