Created attachment 141640 [details] crash log SUMMARY This crash was hard to replicate; sometimes it crashes, and sometimes, it doesn't. This crash is full of ambiguity, but here's the crash log and what step I made. STEPS TO REPRODUCE 1. Create an animation with frame 0 and 1 filled with random brush strokes. 2. Run Render Animation OBSERVED RESULT Immediately after the progress bar, for creating the MP4 file is full, the MP4 file is created and krita crashes. EXPECTED RESULT Krita continues working normally SOFTWARE/OS VERSIONS Windows: 10 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Krita build 1236
Hi there healer.harie, I'm having a hard time reproducing this. I'll see if anyone else can test for this on Windows as well, but I haven't been able to achieve this particular crash. For the sake of more details, would you mind providing me with an FFMPEG version so I can try it using a similar version? I've been using `FFMpeg 4.4-full_build-gyan.dev` available from the gyan website.
The ffmpeg I have was taken from ffmpeg.zeranoe.com, which has stopped providing windows builds. The version I have is N-94597-g74e6800381, released in 2019. Since a possibility of older version of ffmpeg is the cause, I will try updating it.
Created attachment 141892 [details] crash footage Sometimes it took about 3 or 5 times to run Render Animation before Krita crashes. Sometimes it also take 1 times. Tested on Krita build 1244. ffmpeg version 4.4-essentials_build-www.gyan.dev released on 2021.
I've been able to confirm this on another machine. I'll be working on a fix for the next beta. Seems to happen somewhat randomly.
*** Bug 442498 has been marked as a duplicate of this bug. ***
Git commit 556e2bc3b638acfadc463211ab2984466e43a858 by Eoin O'Neill. Committed on 12/10/2021 at 23:34. Pushed by eoinoneill into branch 'master'. Fix crash during animation export by simplifying RAII of ffmpeg subprocess. We were manually cleaning up FFMPEG processes in some parts of the code instead of relying on RAII, which caused some circumstances where the process was freed while QProcess was invoking `waitForProcess`, which seems to crash only on Windows systems. Qt must normally handle this more gracefully on Linux, but can't do so on Windows. We're now avoiding manual cleanup by making more use of QScopedPointer and making our end of the code more clean. Now the process should simply be cleaned up when FFMpegWrapper goes out of scope or is deleted, which should avoid the pointer going null before it is supposed to. M +3 -4 libs/ui/animation/KisDlgImportVideoAnimation.cpp M +7 -11 libs/ui/animation/KisFFMpegWrapper.cpp M +4 -2 libs/ui/animation/KisFFMpegWrapper.h https://invent.kde.org/graphics/krita/commit/556e2bc3b638acfadc463211ab2984466e43a858
Git commit 1a116cb1f28039fb6cfc8105094d80bead72255b by Eoin O'Neill. Committed on 13/10/2021 at 23:12. Pushed by eoinoneill into branch 'krita/5.0'. Fix crash during animation export by simplifying RAII of ffmpeg subprocess. We were manually cleaning up FFMPEG processes in some parts of the code instead of relying on RAII, which caused some circumstances where the process was freed while QProcess was invoking `waitForProcess`, which seems to crash only on Windows systems. Qt must normally handle this more gracefully on Linux, but can't do so on Windows. We're now avoiding manual cleanup by making more use of QScopedPointer and making our end of the code more clean. Now the process should simply be cleaned up when FFMpegWrapper goes out of scope or is deleted, which should avoid the pointer going null before it is supposed to. (cherry picked from commit 556e2bc3b638acfadc463211ab2984466e43a858) M +3 -4 libs/ui/animation/KisDlgImportVideoAnimation.cpp M +7 -11 libs/ui/animation/KisFFMpegWrapper.cpp M +4 -2 libs/ui/animation/KisFFMpegWrapper.h https://invent.kde.org/graphics/krita/commit/1a116cb1f28039fb6cfc8105094d80bead72255b