https://bugs.kde.org/show_bug.cgi?id=522261
--- Comment #5 from Carlos Acevedo <[email protected]> --- Hi, Jean-Baptiste. Unfortunately, the original reproduction scenario is still present. The development build starts, becomes unresponsive during startup, and eventually generates an APPCRASH. The new executable has a different timestamp and different crash offsets, confirming that the new build was indeed tested. I should mention that I am not a programmer, I am actually a musician, haha :) This investigation took me quite a while because I had to learn many things along the way, but if my testing and reports can help improve Kdenlive, I am very happy to contribute. This is the Validation Report, in case it is useful for you: # Validation Report – Development Build 12941 ## Validation of the proposed fix for the Windows startup crash --- # Test environment * Development Build: 12941 * Operating System: Windows 11 * User profile: HP Z2 * Display configuration: Three HP E221 monitors * Original reproduction scenario restored before testing --- # Baseline Before executing the development build, the original configuration that consistently reproduced the crash was restored. Relevant configuration: ```ini [sdl] project_monitor_fullscreen=1:CNC5040FTX ``` This is the same configuration used during the original investigation. --- # Validation objective Determine whether the development build eliminates the original startup crash under exactly the same conditions that reproduced the bug in the released version. --- # Test result ## Original reproduction scenario Result: **FAIL** Observed behavior: * Kdenlive starts. * Startup does not complete. * The application becomes unresponsive. * An APPCRASH is eventually generated. --- # Windows Error Reporting The development build generates a new crash report. Main observations: * Exception: `0xC0000005` * Fault module: `kdenlive.exe` * New executable timestamp * New fault offset: `0x000000000079A890` This confirms that the tested executable is the new development build and not the previous release. --- # WinDbg observations The new dump still reports an: ``` INVALID_POINTER_READ ``` The call stack continues to involve the same general family of operations observed during the original investigation, including: ``` QWidget::setParent QQuickWidget::event QObject::~QObject ``` The offsets naturally differ because this is a different executable, but the overall execution pattern remains very similar. At this point we cannot conclude whether the failure occurs in exactly the same internal function, since no symbols are available for the development build. However, the observed execution pattern remains consistent with the previous investigation. --- # Workaround validation After the failed startup test, the previously discovered workaround was restored: ```ini [sdl] project_monitor_fullscreen= ``` Result: **PASS** Kdenlive starts normally. The application remains usable. No startup crash occurs. --- # Validation matrix Stable Release ``` project_monitor_fullscreen=1:CNC5040FTX → APPCRASH project_monitor_fullscreen= → Starts normally ``` Development Build 12941 ``` project_monitor_fullscreen=1:CNC5040FTX → APPCRASH project_monitor_fullscreen= → Starts normally ``` --- # Experimental conclusions The following statements are supported by reproducible testing. * The original reproduction scenario remains valid. * Clearing `kdockLayout` alone does not eliminate the crash. * Restoring the original fullscreen configuration reproduces the crash in the development build. * Clearing only `project_monitor_fullscreen` prevents the crash both in the stable release and in Development Build 12941. * The previously discovered workaround remains fully effective. * The overall WinDbg stack remains consistent with the original investigation, particularly around `QWidget::setParent`, `QQuickWidget::event`, and `QObject::~QObject`. Based on these observations, the proposed patch does not resolve the original reproduction scenario. --- # Additional observations During the source-code analysis performed throughout the investigation, we identified a number of possible instrumentation ideas that might help isolate the exact point where the invalid pointer originates. These ideas were **not experimentally validated**, because generating an instrumented Windows build would have required setting up a complete KDE/Craft development environment, while the priority shifted to validating the development build you kindly provided. They are therefore included only as possible debugging directions, not as conclusions or proposed fixes. Possible instrumentation ideas include: * Delaying the automatic call to `slotSwitchFullScreen()` until the user interface has completed initialization. * Instrumenting `Monitor::Monitor()` and `slotSwitchFullScreen()`. * Logging object state immediately before and after: * `m_glWidget->setParent(nullptr)` * `showFullScreen()` * Recording: * parent hierarchy * `window()` * `quickWindow()` * screen index * screen serial number * monitor ownership * Temporarily isolating the effects of `setParent(nullptr)` and `showFullScreen()` independently to determine which operation ultimately leads to the invalid pointer observed by WinDbg. These are only potential debugging experiments that emerged from the code analysis and are provided in case they are useful during further investigation. --- # Final conclusion The development build successfully changes the executable under test (new timestamp and new offsets), confirming that the proposed patch was evaluated. However, under the exact same conditions that originally reproduced the bug, the application still crashes during startup. The previously identified workaround continues to prevent the crash. >From the QA perspective, the original reproduction scenario is therefore **not yet resolved**. We hope these results help narrow down the remaining issue, and we would be happy to perform additional validation on future development builds if needed. El dom, 28 jun 2026 a las 5:27, Jean-Baptiste Mardelle (< [email protected]>) escribió: > https://bugs.kde.org/show_bug.cgi?id=522261 > > Jean-Baptiste Mardelle <[email protected]> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|REPORTED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > > --- Comment #4 from Jean-Baptiste Mardelle <[email protected]> --- > Thanks for your detailed report. I don't have a Windows multiple monitor > system > to test right now, but pushed a possible fix in master. > Could you try the latest development builds that contain my fix to confirm > if > this fixes the problem ? > Try installing the daily build from here: > https://origin.cdn.kde.org/ci-builds/multimedia/kdenlive/master/windows/ > > Thanks in advance for your help. > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
