https://bugs.kde.org/show_bug.cgi?id=525453
Bug ID: 525453
Summary: Crash (SIGSEGV, NULL pointer read) opening any project
with an audio track present AND 3+ total tracks
Classification: Applications
Product: kdenlive
Version First 26.08.0
Reported In:
Platform: Other
OS: Microsoft Windows
Status: REPORTED
Severity: crash
Priority: NOR
Component: Timeline & Editing
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Summary:
Crash (SIGSEGV, NULL pointer read) opening any project with an audio track
present AND 3+ total tracks
Steps to Reproduce:
1. Build (or hand-author) a kdenlive_format XML project containing 1 video
track (with a real video clip) and 2 audio tracks. The second audio track can
be completely empty -- no clip needed on it at all.
2. Open the project in Kdenlive.
I confirmed this with 6 controlled minimal test cases (attached:
crashes_2video_1audio.kdenlive, works_3video_noaudio.kdenlive):
1 video + 1 audio (2 tracks total) -> opens fine
1 video + 2 audio, mix transition, real BGM/SE files (4 total) -> CRASH
1 video + 2 audio, no mix transition, shared producer (3 total) -> CRASH
1 video + 2 audio, 2nd audio track completely empty (3 total) -> CRASH
2 video + 1 audio (3 total, only one track is audio) -> CRASH
3 video + 0 audio (3 total, no audio track at all) -> opens fine
So the trigger is not the audio content, not mix transitions, not file path
encoding, and not simply "3+ tracks" on its own -- it is specifically "at least
1 audio track present" AND "3+ total tracks in the sequence".
Observed Result:
Kdenlive crashes (segmentation fault) during or shortly after project load,
every time, with no error dialog.
Expected Result:
The project should open normally, the same way it does with 2 tracks (1 video +
1 audio) or with 3 video-only tracks.
Environment:
Windows 11, build 10.0.26200. Kdenlive 26.08.0 (winget package "KDE.Kdenlive"),
build timestamp 2026-08-28 22:35:26 per the crashing binary's PE header.
Already tried, without success:
- Concurrent Threads (Settings > Configure Kdenlive > Environment > Proxy and
Transcode Jobs) set to 1. This workaround is reported effective for bug 521812
(a similar-looking SIGSEGV during audio waveform generation on Linux), but did
not help here.
- Disabling audio thumbnails entirely (kdenliverc [timeline]
audiothumbnails=false).
- Switching audio backend between WASAPI and DirectSound.
- Manually correcting
kdenlive:sequenceproperties.audioTarget/videoTarget/activeTrack in the project
XML to point at the real track indices (these were found to be stale/hardcoded
by the XML-generating library I used -- an independent, separate bug -- but
correcting them did not change the crash).
Backtrace (WinDbg "!analyze -v" on a saved crash dump, full output attached as
windbg_analyze_v_output.log):
- NULL-pointer READ access violation (AV.Dereference: NullPtr). Faulting
instruction "movsd xmm0, mmword ptr [rax+rdi]" with both rax=0 and rdi=0, i.e.
reading 8 bytes from address 0x0.
- Call stack (innermost first): kdenlive+0x3be020 (crash site) <-
kdenlive+0x3beb75 <- Qt6Widgets!QWidget::event()+0x85d <-
QApplicationPrivate::notify_helper() <- QCoreApplication::sendEvent() <-
QWidgetPrivate::setGeometry_sys() <- QWidget::resize() <-
QWidget::setMaximumSize() <- QWidget::setMaximumHeight() <- kdenlive+0x3bd058
<- kdenlive+0x3be762 <- Qt6Core!QMetaCallEvent::placeMetaCall() <-
QObject::event() <- ... <- QCoreApplicationPrivate::sendPostedEvents()
- The crash happens synchronously while handling a queued Qt signal/slot call
that ends up calling QWidget::setMaximumHeight() on some per-track widget,
triggering a resize event whose handler dereferences a null pointer.
- kdenlive.exe ships no public PDB and the crash address does not resolve
against any exported symbol, so I could not get exact function/class names.
Given the call chain goes through setMaximumHeight-triggered resize handling,
this looks consistent with per-track UI widget layout code (e.g. audio mixer
strips or track headers) that assumes an invariant which doesn't hold once 3+
tracks including audio are present.
I have the crash dump, the minimal reproduction .kdenlive files (both a
crashing and a non-crashing case), and the full !analyze -v output, attached to
this report.
--
You are receiving this mail because:
You are watching all bug changes.
