Details
-
Bug
-
Resolution: Fixed
-
P1: Critical
-
6.4.1
-
None
-
-
c3a5fe2fd (dev), 9d14e35e7 (6.5), 9bbf76137 (6.4)
Description
When building and running OBS Studio 29.0.0-beta2 on Windows 11 21H2 (or Win10 22H2) with VS2022 (17.4) in Debug with Qt 6.4.1, I encounter an assert with the following steps:
- Open OBS Studio (preferably in portable mode to ensure default settings).
- Open Settings dialog.
- If you made it past Step 2, on the left-hand side, select Output.
- Set Output Mode to Advanced.
- On the right-hand side, select the Recording tab.
Here is the assert dialog text (image also attached):
Program: ...roject\obs-studio\build64\rundir\Debug\bin\64bit\Qt6Cored.dll Module: 6.4.1 File: D:\a\obs-deps\obs-deps\windows_build_temp\qt6_build\6.4.1\x64\qtbase\include\QtCore\../../../../../../qt6/qtbase/src/corelib/tools/qlist.h Line: 428 ASSERT failure in QList::operator[]: "index out of range", file D:\a\obs-deps\obs-deps\windows_build_temp\qt6_build\6.4.1\x64\qtbase\include\QtCore\../../../../../../qt6/qtbase/src/corelib/tools/qlist.h, line 428
This did not occur with Qt 6.3.1. It reportedly does not occur with Qt 6.4.1 in Debug builds on macOS, though I will work to confirm this.
Commenting out either of these lines in OBS Studio's code also prevents the assert:
- https://github.com/obsproject/obs-studio/blob/29.0.0-beta2/UI/window-basic-settings.cpp#L4754
- https://github.com/obsproject/obs-studio/blob/29.0.0-beta2/UI/window-basic-settings.cpp#L4759
You will also hit the assert if you were to replace the `setWordWrap` line with:
formLayout->setRowWrapPolicy(QFormLayout::WrapLongRows);
With Qt 6.4.1, the assert will show up after Step 5. While I was bisecting Qt, I discovered that the assert can happen after Step 2. I bisected Qt to determine that the assert will show up after Step 2 above at commit a74cdf778c0c72fa22d9354207d729b2cbf88128 (GitHub, Qt Code Review). Perhaps a later commit changed behavior slightly, resulting in it only appearing after Step 5. I notice a similar assert was observed back in March, which was fixed by commit 182255052966d2163cfe0e16bf267925894abac8 (GitHub, Qt Code Review). The very first commit in my bisect was before this amended change, so that might explain the observed behavior difference.
I haven't yet produced a minimal test case for this. I'm hoping that this information is enough to determine a cause, or if this is a Qt bug at all. If necessary, I can work on producing a smaller test case.