https://bugs.kde.org/show_bug.cgi?id=505578
--- Comment #17 from [email protected] --- (In reply to Yash Bavadiya from comment #16) > I had a look at the two backtraces with debug symbols (attachments 183612 > and 183613), and both crash in the same place, inside MLT's avformat > producer rather than in Kdenlive code. > > Attachment 183613 [details], thread 20303: > > ``` > #0 avformat_find_stream_info () at /app/lib/libavformat.so.61 > #1 get_basic_info (...) at producer_avformat.c:911 > #2 producer_open (..., take_lock=0, test_open=0) at producer_avformat.c:1178 > #3 producer_set_up_video (...) at producer_avformat.c:2988 > ``` > > Attachment 183612 [details], thread 1 (the main thread): > > ``` > #0 producer_open (..., take_lock=0, test_open=0) at producer_avformat.c:1241 > ``` > > Two things stand out. Both crashes are in `producer_open` reached from the > lazy reopen path, the "Reopen the file if necessary" branch that runs when > the format context is null, and in both cases `take_lock=0`, so the producer > is being opened without taking its own internal lock. The video reopen path > passes `take_lock=0` and locks `video_mutex` by hand around the call, while > the audio reopen path passes `take_lock=1`, so the locking is asymmetric > between the two. > > The other thing is that one crash is on a worker thread and the other is on > the main thread, and both dumps have 18 threads inside producer_avformat.c > at the moment of the crash. That fits the "random, happens when I am not > expecting it" description better than a specific user action does, since > what varies is the timing rather than the operation. The reported triggers, > dragging a clip, moving the playhead, zooming, importing, are all things > that cause producers to be opened or reopened. > > Worth noting the file in 183613 is a .webm and in 183612 a proxy .mov, so it > does not look format specific. > > I have not reproduced this locally and I am not claiming a specific root > cause, the line numbers in the trace are from the AppImage's MLT build so > they do not map exactly onto current MLT sources. But the crash is > consistently in that reopen path, so that seems like the place to look, and > it may be worth raising upstream with MLT rather than treating it as a > Kdenlive bug. > > @antimidia if you hit it again, a backtrace from a debug build would help > narrow it further, the two attachments above are the only ones in the ticket > with symbols and they are from 2025. Yeah, I can do that. I'll start using the flatpak version to be able to provide more debug logs. -- You are receiving this mail because: You are watching all bug changes.
