Closed amitdhiman000 closed 6 months ago
ChristianFeldmann
commented
12 months ago Thanks for the report. So you are on an intel Mac, right? Unfortunately I do not own an intel or Arm mac so this will be a bit hard for me to debug ...
The crash log definitely matches your report. Nothing special seems to be happening. The call stack shows that focus() was called which probably happens when you click anywhere on the screen.
th1nk3r-ing
commented
11 months ago same problem on intel mbp.
th1nk3r-ing
commented
11 months ago same problem on intel mbp.
v2.13 is OK, while v2.14 has crash problem.
amitdhiman000
commented
11 months ago Thanks for the report. So you are on an intel Mac, right? Unfortunately I do not own an intel or Arm mac so this will be a bit hard for me to debug ... The crash log definitely matches your report. Nothing special seems to be happening. The call stack shows that
focus()was called which probably happens when you click anywhere on the screen.
Yes it is on Intel Mac. I think it was working fine with v2.13, But then I got a prompt to update to latest version v2.14 and it started crashing. I confirmed by running v2.13, it works fine.
ChristianFeldmann
commented
11 months ago Ok so far I was not able to obtain an intel mac to test this. I will try again this week. Was looking on ebay for a device. Would also accept an old donor mac :)
ChristianFeldmann
commented
9 months ago I now have an M1 macbook and I am able to reproduce this with a native build using qt 6.6.1 (installed via homebrew) and a native build. I can see the same call stack. It goes into notfy for a mouse move event and then crashes in QWidget::hide with a EXC_BAD_ACCESS and some null address.
The debug stack unfortunately does not reveal much more than this. With a debug version of Qt this may be more informative. So I compile Qt from source in debug mode. This is a bit more informative. Somehow it crashes when up dating the layout of the playlistItemWidget (maybe) and then there is some seperator widget which is nullptr:
Looks like this PR might be related to this crash: https://github.com/qt/qtbase/commit/9943cf73717a497c7fec5989968311abd9f5d61b. Issue: https://bugreports.qt.io/browse/QTCREATORBUG-24600 Maybe this is missing a null check (if this can even be null). I will see if a check fixes it and maybe I can open a bug report in Qt.
ChristianFeldmann
commented
9 months ago Its getting stranger and stranger. I dug a bit into the code of these used/unused separators and the reason why there is a null separator in this list. As I understood the list, it is more for "recycling" separators. I ended up in QDockAreaLayout::updateSeparatorWidgets. Code of the function:
void QDockAreaLayout::updateSeparatorWidgets() const
{
int j = 0;
for (int i = 0; i < QInternal::DockCount; ++i) {
const QDockAreaLayoutInfo &dock = docks[i];
if (dock.isEmpty())
continue;
QWidget *sepWidget;
if (j < separatorWidgets.size()) {
sepWidget = separatorWidgets.at(j);
if (!sepWidget) {
qWarning("QDockAreaLayout::updateSeparatorWidgets: null separator widget");
sepWidget = qt_mainwindow_layout(mainWindow)->getSeparatorWidget();
separatorWidgets[j] = sepWidget;
}
} else {
sepWidget = qt_mainwindow_layout(mainWindow)->getSeparatorWidget();
separatorWidgets.append(sepWidget);
}
j++;
Q_ASSERT(sepWidget);
sepWidget->raise();
QRect sepRect = separatorRect(i).adjusted(-2, -2, 2, 2);
sepWidget->setGeometry(sepRect);
sepWidget->setMask( QRegion(separatorRect(i).translated( - sepRect.topLeft())));
sepWidget->show();
}
for (int i = j; i < separatorWidgets.size(); ++i)
separatorWidgets.at(i)->hide();
separatorWidgets.resize(j);
}I debugged on my mac and what happens is that in the last line (resize to j items), the null items are added. I added some debug code and it happens here that j is larger then the size of separatorWidgets. This happens because in one loop, when calling sepWidget->show();, some sort of layout restoration happens and the layout is reset, which clears the list separatorWidgets. Now j is > 0 and the list is empty and this function does not work as intended anymore. So another possible fix would be to only resize the list here if j is smaller then the size of the list.
I will:
ChristianFeldmann
commented
8 months ago I just had a tiny bit of time to continue debugging and suddenly I was not able to reproduce the error. It was just working as expected. I then installed the older version 5.13 and then reinstalled 5.14 and there the bug was back. I have a new theory that this has to do with some code that we are using for UI handling and restoring. I think we store/reload the UI state from the QtSettings when reloading YUView so that it looks identical to the last time you launched it. My new theory is that this storing/loading does not work across the Qt versions. I will check this theory.
Yep that is the issue. See description in PR https://github.com/IENT/YUView/pull/557. It looks like storing and loading the state data can crash YUView on macos if this is done across different Qt versions.
ChristianFeldmann
commented
8 months ago @amitdhiman000 I merged a fix for this crash. It would be great if you could test this on your machine too. You just have to compile the latest develop branch (which includes the fix) in release mode:
mkdir build
cd build
qmake ../
make -j 8and then this release build version should work (hopefully). Thanks again for the report. This was a really strange one.
ChristianFeldmann
commented
6 months ago Fixed from my side. Please reopen if this still occurs.
Describe the bug YUView crashing on each launch, callstack report below.
To Reproduce Steps to reproduce the behavior:
Expected behavior Expected to work without any crash
Screenshots N/A
Version (please complete the following information):