https://bugs.kde.org/show_bug.cgi?id=479524
Bug ID: 479524
Summary: Kdelive opens many files on project load
Classification: Applications
Product: kdenlive
Version: 23.08.1
Platform: Ubuntu
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: Video Display & Export
Assignee: j...@kdenlive.org
Reporter: k...@psycoti.ca
Target Milestone: ---
SUMMARY
I have a project with 359 clips, and kdenlive crashes when opening the project
unless I set the process's "open file limit" to between 2048 and 4096.
STEPS TO REPRODUCE
1. Open the project, either by starting Kdenlive and then picking the project,
or opening the project file from the fs
OBSERVED RESULT
A progress bar is shown for a while, and then the program crashes.
EXPECTED RESULT
My project loads.
SOFTWARE/OS VERSIONS
Kdenlive: 23.08.1
Package Type: Unknown/Default
MLT: 7.18.0
Qt: 5.15.10 (built against 5.15.10 x86_64-little_endian-lp64)
Frameworks: 5.110.0
System: Ubuntu 23.10
Kernel: linux 6.5.0-14-generic
CPU: x86_64
Windowing System: xcb
Movit (GPU): disabled
Track Compositing: qtblend
ADDITIONAL INFORMATION
This one was tricky to track down. Running it in gdb I originally thought it
was a bug in avformat, because that's where the segfaults were coming from. For
a while I thought the problem was maybe that one of the clips had become
corrupted in some way, because I had been able to work with the project for
hours, it was only when I closed the app and reopened it later that it had
become unopenable. From the backtrace it seemed like avformat was failing to
read the codec because the error was a segfault on a line that looked like
`avformat_find_stream_info(self->video_format, NULL)`
Turns out (after re-encoding all of my clips, etc etc) that this was a red
herring. The _actual_ issue was that the `get_basic_info` function in
`modules/avformat/producer_avformat.c` calls
`avformat_open_input(&self->video_format, filename, NULL, NULL)` to populate
that "video_format" struct, but doesn't look at the return value and moves
right on to the `avformat_find_stream_info` with a null structure which causes
the segfault. Which sucks, and could arguably be considered a bug in avformat.
But more importantly when I instrumented that line to report the error it was
getting, it was -24, which is "too many open files". So not really a
recoverable bug inside avformat maybe...
But from the outside of avformat, though, it seems a bit nuts to me that if my
project has 350 clips, that simply loading the project causes it to exhaust
1024 fds, apparently all at once, and crash unhelpfully. At the time I thought
it might be corruption of the proxy files, and I deleted those. So by the time
I figured out what the problem actually was, loading the project had to not
only open the files, but also rebuild the proxy files, which I'm sure makes the
problem even worse. So upping the file limit to 2048 still caused it to crash,
it just took longer to crash. But setting it to 4096 allowed the project to
open and rebuild.
All in all, while that one behaviour in avformat doesn't seem awesome, it feels
like a more fundamental Kdenlive problem that it's touching all of these files
in the first place. Now that the project is loaded, and all of the proxy clips
are rebuilt, my process appears to be hanging out around 3660 lines in `lsof -p
1376913 | wc -l` and 2154 in `ls /proc/1376913/fd | wc -l`, which feels like a
lot for a project with 350 clips and 3 sequences. That's like, what, 10 fds per
clip in the bin?
I haven't even _used_ most of the clips yet. I'm only 3 or so scenes into the
edit, so only about 42 of the clips are referenced in any sequence. Is this
expected behaviour?
I don't have a proper dump, but here's the last 5 frames that gdb gave me from
my backscroll just so you can see what I'm talking about:
```
Thread 1 "kdenlive" received signal SIGSEGV, Segmentation fault.
0x00007fffaf499ff9 in avformat_find_stream_info (ic=0x0,
options=options@entry=0x0) at src/libavformat/demux.c:2430
Downloading source file
/usr/src/ffmpeg-7:6.0-6ubuntu1/debian/standard/src/libavformat/demux.c
2430 src/libavformat/demux.c: No such file or directory.
(gdb) bt 5
#0 0x00007fffaf499ff9 in avformat_find_stream_info (ic=0x0,
options=options@entry=0x0) at src/libavformat/demux.c:2430
#1 0x00007fffb44db665 in get_basic_info (filename=0x55556a998ab0 "[REDACTED
PATH TO CLIP]", profile=0x555556648fa0, self=0x555598a075a0)
at /usr/src/mlt-7.18.0-1/src/modules/avformat/producer_avformat.c:770
#2 producer_open
(self=self@entry=0x555598a075a0, profile=0x555556648fa0,
URL=URL@entry=0x5555793aa1b0 "[REDACTED PATH TO CLIP]",
take_lock=take_lock@entr
y=1, test_open=test_open@entry=0) at
/usr/src/mlt-7.18.0-1/src/modules/avformat/producer_avformat.c:1035
#3 0x00007fffb44dc682 in producer_set_up_audio (frame=0x55557974b820,
self=0x555598a075a0) at
/usr/src/mlt-7.18.0-1/src/modules/avformat/producer_avformat.c:3524
#4 producer_get_frame (producer=0x555598d71210, frame=<optimized out>,
index=<optimized out>) at
/usr/src/mlt-7.18.0-1/src/modules/avformat/producer_avformat.c:3638
```
--
You are receiving this mail because:
You are watching all bug changes.
