I'm trying to use "shotcut", installed in a Fedora 41 virtual machine, to split up some large mp4 files. It can read the files and play the videos just fine, so there is apparently no decoder issue, but any time I try to do anything with the file the process segfaults. Suspecting there might be a memory issue with these large files (7.5GB on the largest, but same result on an 862MB file), I increased the VM's memory allocation to 32GB. No difference. There is no sign that the system is running out of memory.
Here is a typical sequence: Create a new project, "Test1", Drag an mp4 file from the "Recent" area into the Playlist, Double-click on the Playlist snapshot to select it and start the video playing, After about 90 seconds, without doing enything else, the process segfaults.
Heck, I find that if I just drag the mp4 into the playlist and do nothing else (not even playing the video), the process still segfaults after about 2 minutes, all of this with no appreciable CPU activity in the meantime.
Here's the tail of the generated shotcutlog.txt file:
[Info ] MainWindow::open "/Public/S862M.mp4" [Debug ] Playlist::InsertCommand::redo row 0 [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [consumer sdl2_audio] Audio Opened: driver=pulseaudio channels=2 frequency=48000 [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] Util::isMemoryLow available RAM = 31469388 KB [Debug ] <autosaveTask> Function autosaveTask finished in 3 ms. [Info ] Util::isMemoryLow available RAM = 31472564 KB
Nothing obvious in the journal:
May 17 22:14:00 fedora-vm.local audit[2788]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2> May 17 22:14:00 fedora-vm.local kernel: show_signal_msg: 40 callbacks suppressed May 17 22:14:00 fedora-vm.local kernel: Thread (pooled)[2893]: segfault at 358 ip 00007f04a0a81494 sp 00007f04864f2378 error 4 in libc.so.6[74494,7f04a0a0> May 17 22:14:00 fedora-vm.local kernel: Code: da f9 ff 48 8d 0d 7c 74 14 00 ba c2 01 00 00 48 8d 35 80 ea 13 00 48 8d 3d 8e ea 13 00 e8 14 da f9 ff 0f 1f > May 17 22:14:00 fedora-vm.local systemd-coredump[2894]: Process 2788 (shotcut) of user 1000 terminated abnormally with signal 11/SEGV, processing... May 17 22:14:00 fedora-vm.local systemd[1]: Created slice system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump. May 17 22:14:00 fedora-vm.local audit: BPF prog-id=71 op=LOAD May 17 22:14:00 fedora-vm.local audit: BPF prog-id=72 op=LOAD May 17 22:14:00 fedora-vm.local audit: BPF prog-id=73 op=LOAD May 17 22:14:00 fedora-vm.local systemd[1]: Started systemd-coredump@0-2894-0.service - Process Core Dump (PID 2894/UID 0). May 17 22:14:00 fedora-vm.local audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-core> May 17 22:14:00 fedora-vm.local abrt-dump-journal-core[983]: Failed to obtain all required information from journald May 17 22:14:01 fedora-vm.local systemd-coredump[2895]: [🡕] Process 2788 (shotcut) of user 1000 dumped core. {Huge module list and stack trace deleted}
I don't know what is happening -- perhaps some timed auto-save that blows up?? (I don't see any setting to disable that.)
On Sat, May 17, 2025 at 11:30 PM Robert Nichols via users users@lists.fedoraproject.org wrote:
I'm trying to use "shotcut", installed in a Fedora 41 virtual machine, to split up some large mp4 files. It can read the files and play the videos just fine, so there is apparently no decoder issue, but any time I try to do anything with the file the process segfaults. Suspecting there might be a memory issue with these large files (7.5GB on the largest, but same result on an 862MB file), I increased the VM's memory allocation to 32GB. No difference. There is no sign that the system is running out of memory.
Here is a typical sequence: Create a new project, "Test1", Drag an mp4 file from the "Recent" area into the Playlist, Double-click on the Playlist snapshot to select it and start the video playing, After about 90 seconds, without doing enything else, the process segfaults.
Heck, I find that if I just drag the mp4 into the playlist and do nothing else (not even playing the video), the process still segfaults after about 2 minutes, all of this with no appreciable CPU activity in the meantime.
Here's the tail of the generated shotcutlog.txt file:
[Info ] MainWindow::open "/Public/S862M.mp4" [Debug ] Playlist::InsertCommand::redo row 0 [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [consumer sdl2_audio] Audio Opened: driver=pulseaudio channels=2 frequency=48000 [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] <MLT> [link swresample] 2(stereo) f32le 44100Hz -> 2(stereo) s16 48000Hz [Info ] Util::isMemoryLow available RAM = 31469388 KB [Debug ] <autosaveTask> Function autosaveTask finished in 3 ms. [Info ] Util::isMemoryLow available RAM = 31472564 KB
Nothing obvious in the journal:
May 17 22:14:00 fedora-vm.local audit[2788]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2> May 17 22:14:00 fedora-vm.local kernel: show_signal_msg: 40 callbacks suppressed May 17 22:14:00 fedora-vm.local kernel: Thread (pooled)[2893]: segfault at 358 ip 00007f04a0a81494 sp 00007f04864f2378 error 4 in libc.so.6[74494,7f04a0a0> May 17 22:14:00 fedora-vm.local kernel: Code: da f9 ff 48 8d 0d 7c 74 14 00 ba c2 01 00 00 48 8d 35 80 ea 13 00 48 8d 3d 8e ea 13 00 e8 14 da f9 ff 0f 1f > May 17 22:14:00 fedora-vm.local systemd-coredump[2894]: Process 2788 (shotcut) of user 1000 terminated abnormally with signal 11/SEGV, processing... May 17 22:14:00 fedora-vm.local systemd[1]: Created slice system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump. May 17 22:14:00 fedora-vm.local audit: BPF prog-id=71 op=LOAD May 17 22:14:00 fedora-vm.local audit: BPF prog-id=72 op=LOAD May 17 22:14:00 fedora-vm.local audit: BPF prog-id=73 op=LOAD May 17 22:14:00 fedora-vm.local systemd[1]: Started systemd-coredump@0-2894-0.service - Process Core Dump (PID 2894/UID 0). May 17 22:14:00 fedora-vm.local audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-core> May 17 22:14:00 fedora-vm.local abrt-dump-journal-core[983]: Failed to obtain all required information from journald May 17 22:14:01 fedora-vm.local systemd-coredump[2895]: [🡕] Process 2788 (shotcut) of user 1000 dumped core. {Huge module list and stack trace deleted}
I don't know what is happening -- perhaps some timed auto-save that blows up?? (I don't see any setting to disable that.)
Attach a debugger and wait for the process to crash. See, for example, https://sourceware.org/gdb/current/onlinedocs/gdb.html/Attach.html.
Jeff
On 5/18/25 00:17, Jeffrey Walton wrote:
On Sat, May 17, 2025 at 11:30 PM Robert Nichols via users users@lists.fedoraproject.org wrote:
I'm trying to use "shotcut", installed in a Fedora 41 virtual machine, to split up some large mp4 files. It can read the files and play the videos just fine, so there is apparently no decoder issue, but any time I try to do anything with the file the process segfaults. Suspecting there might be a memory issue with these large files (7.5GB on the largest, but same result on an 862MB file), I increased the VM's memory allocation to 32GB. No difference. There is no sign that the system is running out of memory.
[SNIP]
Attach a debugger and wait for the process to crash. See, for example, https://sourceware.org/gdb/current/onlinedocs/gdb.html/Attach.html.
Jeff
Sorry about the delay. Life intervened, and I also wanted to set up a physical machine to see if running on the bare hardware behaved the same as in a virtual machine. It did. Plus, I tried it with a short (<60 sec) video shot with my own camera. Same behavior. Output from gdb after several screenfuls of downloading debug information yielded:
Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f9576cf47b0 in __GI_ppoll (fds=fds@entry=0x55bd51f4a460, nfds=nfds@entry=5, timeout=<optimized out>, timeout@entry=0x7ffdb932a5c0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42 42 return SYSCALL_CANCEL (ppoll_time64, fds, nfds, timeout, sigmask, --Type <RET> for more, q to quit, c to continue without paging--c Missing rpms, try: dnf --enablerepo='*debug*' install ffmpeg-libs-debuginfo-7.1.1-6.fc41.x86_64 libavdevice-debuginfo-7.1.1-6.fc41.x86_64 vvenc-libs-debuginfo-1.13.1-3.fc41.x86_64 x264-libs-debuginfo-0.164-15.20231001git31e19f92.fc41.x86_64 x265-libs-debuginfo-3.6-3.fc41.x86_64 openh264-debuginfo-2.4.1-2.fc41.x86_64 (gdb) c Continuing. [Thread 0x7f952a9fe6c0 (LWP 3871) exited] [Thread 0x7f95477fe6c0 (LWP 3868) exited] [Thread 0x7f9547fff6c0 (LWP 3867) exited] [New Thread 0x7f9547fff6c0 (LWP 3888)] [New Thread 0x7f95477fe6c0 (LWP 3889)] [New Thread 0x7f952a9fe6c0 (LWP 3890)] [New Thread 0x7f95050a96c0 (LWP 3891)] [New Thread 0x7f95048a86c0 (LWP 3892)] [New Thread 0x7f94fbfff6c0 (LWP 3893)] [New Thread 0x7f94fb7fe6c0 (LWP 3894)] [New Thread 0x7f94faffd6c0 (LWP 3895)] [New Thread 0x7f94fa7fc6c0 (LWP 3896)] [New Thread 0x7f94f9ffb6c0 (LWP 3897)] [New Thread 0x7f94f97fa6c0 (LWP 3898)] [New Thread 0x7f94f8ff96c0 (LWP 3899)] [New Thread 0x7f94f87f86c0 (LWP 3901)] [Thread 0x7f95477fe6c0 (LWP 3889) exited] [Thread 0x7f9547fff6c0 (LWP 3888) exited]
Thread 23 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f952a9fe6c0 (LWP 3890)] ___pthread_mutex_lock (mutex=mutex@entry=0x2aed4278d06f824f) at pthread_mutex_lock.c:80 80 unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex); (gdb) c Continuing. [New Thread 0x7f9547fff6c0 (LWP 3914)] [Thread 0x7f9547fff6c0 (LWP 3914) exited] [Thread 0x7f94f87f86c0 (LWP 3901) exited] [Thread 0x7f94f8ff96c0 (LWP 3899) exited] [Thread 0x7f94f97fa6c0 (LWP 3898) exited] [Thread 0x7f94f9ffb6c0 (LWP 3897) exited] [Thread 0x7f94fa7fc6c0 (LWP 3896) exited] [Thread 0x7f94faffd6c0 (LWP 3895) exited] [Thread 0x7f94fb7fe6c0 (LWP 3894) exited] [Thread 0x7f94fbfff6c0 (LWP 3893) exited] [Thread 0x7f952a9fe6c0 (LWP 3890) exited] [Thread 0x7f95067fc6c0 (LWP 3879) exited] [Thread 0x7f95077fe6c0 (LWP 3877) exited] [Thread 0x7f9507fff6c0 (LWP 3876) exited] [Thread 0x7f95189fe6c0 (LWP 3875) exited] [Thread 0x7f95191ff6c0 (LWP 3874) exited] [Thread 0x7f95299626c0 (LWP 3873) exited] [Thread 0x7f952a1636c0 (LWP 3872) exited] [Thread 0x7f952b1ff6c0 (LWP 3870) exited] [Thread 0x7f9546ffd6c0 (LWP 3869) exited] [Thread 0x7f955d4096c0 (LWP 3866) exited] [Thread 0x7f955dd2c6c0 (LWP 3864) exited] [Thread 0x7f955e52d6c0 (LWP 3863) exited] [Thread 0x7f955ed2e6c0 (LWP 3862) exited] [Thread 0x7f955ffff6c0 (LWP 3861) exited] [Thread 0x7f9564fa46c0 (LWP 3860) exited] [Thread 0x7f9575563200 (LWP 3857) exited] [Thread 0x7f95050a96c0 (LWP 3891) exited] [Thread 0x7f9506ffd6c0 (LWP 3878) exited] [Thread 0x7f95048a86c0 (LWP 3892) exited] [New process 3857]
Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) q
If this were not clearly distributed as "free software" I would suspect a timeout due to lack of a license.
On 30 May 2025, at 14:14, Robert Nichols via users users@lists.fedoraproject.org wrote:
___pthread_mutex_lock (mutex=mutex@entry=0x2aed4278d06f824f) at pthread_mutex_lock.c:80 80 unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex);
That mutex address looks bad. Getting a back trace will be useful for reporting this bug. At the gdb prompt do `bt`.
Barry
On 5/30/25 10:23, Barry wrote:
On 30 May 2025, at 14:14, Robert Nichols via users users@lists.fedoraproject.org wrote:
___pthread_mutex_lock (mutex=mutex@entry=0x2aed4278d06f824f) at pthread_mutex_lock.c:80 80 unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex);
That mutex address looks bad. Getting a back trace will be useful for reporting this bug. At the gdb prompt do `bt`.
Barry
Thread 59 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fe5bbdfe6c0 (LWP 8783)] ___pthread_mutex_lock (mutex=mutex@entry=0x4054c00000000348) at pthread_mutex_lock.c:80 80 unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex); (gdb) bt #0 ___pthread_mutex_lock (mutex=mutex@entry=0x4054c00000000348) at pthread_mutex_lock.c:80 #1 0x00007fe60b83580c in mlt_properties_inc_ref (self=<optimized out>) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_properties.c:366 #2 mlt_properties_inc_ref (self=<optimized out>) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_properties.c:361 #3 0x00007fe60b86d072 in Mlt::Service::Service (this=<optimized out>, service=<optimized out>, this=<optimized out>, service=<optimized out>) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/mlt++/MltService.cpp:46 #4 0x00007fe60b86d5f8 in Mlt::Service::consumer ( this=this@entry=0x7fe5bbdfd470) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/mlt++/MltService.cpp:120 #5 0x00005649c04ca6aa in Mlt::Controller::saveXML (this=0x5649cf47a8c8, filename=..., service=<optimized out>, withRelativePaths=<optimized out>, tempFile=0x0, proxy=false, projectNote=...) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mltcontroller.cpp:504 #6 0x00005649c04a8f0a in MainWindow::saveXML (this=0x5649cf691740, filename=..., withRelativePaths=false) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mainwindow.cpp:3636 #7 0x00005649c0495609 in MainWindow::doAutosave (this=0x5649cf691740) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mainwindow.cpp:1735 --Type <RET> for more, q to quit, c to continue without paging-- #8 autosaveTask (p=0x5649cf691740) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mainwindow.cpp:1913 #9 0x00005649c03a9aea in QtConcurrent::RunFunctionTaskBase<void>::run ( this=0x5649d62df070) at /usr/include/qt6/QtConcurrent/qtconcurrentrunbase.h:83 #10 0x00007fe6088bfbf3 in QThreadPoolThread::run (this=0x5649cfdb73f0) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthreadpool.cpp:71 #11 0x00007fe6088b67e9 in operator() (__closure=<optimized out>) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthread_unix.cpp:375 #12 (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=...) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthread_unix.cpp:311 #13 QThreadPrivate::start (arg=0x5649cfdb73f0) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthread_unix.cpp:339 #14 0x00007fe60807dfa8 in start_thread (arg=<optimized out>) at pthread_create.c:448 #15 0x00007fe608101fcc in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 (gdb)
Good luck trying to dig anything out of that. All I did to provoke that was:
1. Start a new project, "Test1". 2. Drag a short (40 second) video from the "Recent" panel into the "Playlist" panel. 3. Double-click on the video in the Playlist panel and allow it to play out.
Shortly after the video finishes playing, the SEGFAULT occurs. (On a longer video, the SEGFAULT occurs after about the same time, while the video is still playing.)
I can also get a similar failure without playing the video at all. Just replace step 3 with:
3. From the "Playlist" hamburger menu, click on "Add Selected to Timeline".
Just wait about 90 seconds (without doing anything in the shotcut window) and a SEGFAULT occurs:
Thread 40 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fc5c27fe6c0 (LWP 11439)] 0x00007fc6122e5858 in mlt_properties_dec_ref (self=0x61) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_properties.c:383 383 if (self != NULL) { (gdb) bt #0 0x00007fc6122e5858 in mlt_properties_dec_ref (self=0x61) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_properties.c:383 #1 0x00007fc6122f296e in mlt_service_close (self=0x61) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_service.c:871 #2 mlt_service_close (self=0x61) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_service.c:869 #3 0x00007fc6122f29fb in mlt_service_close (self=0x7fc5b4137790) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_service.c:884 #4 mlt_service_close (self=0x7fc5b4137790) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/framework/mlt_service.c:869 #5 0x00007fc612315887 in Mlt::Service::~Service (this=<optimized out>, this=<optimized out>) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/mlt++/MltService.cpp:55 #6 0x00007fc6123158b5 in Mlt::Service::~Service (this=<optimized out>, this=<optimized out>) at /usr/src/debug/mlt-7.32.0-1.fc41.x86_64/src/mlt++/MltService.cpp:56 #7 0x000055eede2cab7a in std::default_deleteMlt::Service::operator() ( this=<optimized out>, __ptr=0x7fc5d00be1e0) at /usr/include/c++/14/bits/unique_ptr.h:87 #8 std::unique_ptr<Mlt::Service, std::default_deleteMlt::Service >::~unique_ptr (this=<optimized out>, this=<optimized out>) at /usr/include/c++/14/bits/unique_ptr.h:399 --Type <RET> for more, q to quit, c to continue without paging--c #9 Mlt::Controller::saveXML (this=0x55eeee1f4928, filename=..., service=<optimized out>, withRelativePaths=<optimized out>, tempFile=0x0, proxy=false, projectNote=...) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mltcontroller.cpp:545 #10 0x000055eede2a8fd9 in MainWindow::saveXML (this=0x55eeee3a48f0, filename=..., withRelativePaths=<optimized out>) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mainwindow.cpp:3630 #11 0x000055eede295609 in MainWindow::doAutosave (this=0x55eeee3a48f0) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mainwindow.cpp:1735 #12 autosaveTask (p=0x55eeee3a48f0) at /usr/src/debug/shotcut-25.05.11-1.fc41.x86_64/src/mainwindow.cpp:1913 #13 0x000055eede1a9aea in QtConcurrent::RunFunctionTaskBase<void>::run ( this=0x55eef4cb82e0) at /usr/include/qt6/QtConcurrent/qtconcurrentrunbase.h:83 #14 0x00007fc60f2bfbf3 in QThreadPoolThread::run (this=0x55eeeeaca240) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthreadpool.cpp:71 #15 0x00007fc60f2b67e9 in operator() (__closure=<optimized out>) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthread_unix.cpp:375 #16 (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=...) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthread_unix.cpp:311 #17 QThreadPrivate::start (arg=0x55eeeeaca240) at /usr/src/debug/qt6-qtbase-6.8.2-3.fc41.x86_64/src/corelib/thread/qthread_unix.cpp:339 #18 0x00007fc60ea7dfa8 in start_thread (arg=<optimized out>) at pthread_create.c:448 #19 0x00007fc60eb01fcc in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 (gdb)
Has anybody actually used this program? Since it fails for me in two different environments, I can't see how.
On 5/30/25 17:57, Robert Nichols via users wrote:
Thread 59 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fe5bbdfe6c0 (LWP 8783)] ___pthread_mutex_lock (mutex=mutex@entry=0x4054c00000000348)
...
Looks like I'm not alone. I've added this to https://bugzilla.redhat.com/show_bug.cgi?id=2368262 .
On 5/30/25 17:57, Robert Nichols via users wrote:
On 5/30/25 10:23, Barry wrote:
On 30 May 2025, at 14:14, Robert Nichols via users users@lists.fedoraproject.org wrote:
Has anybody actually used this program? Since it fails for me in two different environments, I can't see how.
Well, the "Linux portable tar" version of Shotcut 25.05.11 downloaded from www.shotcut.org seems to work just fine. Looks like it's just the shotcut-25.05.11-1.fc41.x86_64.rpm version that is broken.
-
Barry -
Jeffrey Walton -
Robert Nichols