Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-109237

[Reg-6.3.1->6.4.1] Calling formLayout->addRow can result in assert in Debug builds

    XMLWordPrintable

Details

    • Windows
    • 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:

      1. Open OBS Studio (preferably in portable mode to ensure default settings).
      2. Open Settings dialog.
      3. If you made it past Step 2, on the left-hand side, select Output.
      4. Set Output Mode to Advanced.
      5. 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:

      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.

      Attachments

        For Gerrit Dashboard: QTBUG-109237
        # Subject Branch Project Status CR V

        Activity

          People

            vhilshei Volker Hilsheimer
            rytoex Ryan Foster
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes