fatal assert: The application's primary screen should always be in sync with the main display

[davecotter]

in Designer, i create a window that has a QOpenGLWidget. this window is initially hidden.

when i run my app and go to show it, i get this assert:

The application's primary screen should always be in sync with the main display

and the app just aborts.

if i delete the OGL widget, the app runs fine. (but no OGL widget, obvs)

it seems that creating the widget "offscreen" (ie not showing) gives it an unexpected QCocoaScreen (cuz it's not ON a screen to begin with?)

any idea what is going on?

[davecotter]

note i'm on a laptop with just the built-in monitor, no secondary monitor.

[SGaist]

Hi,

What model of laptop is it ?
What version of macOS are you running ?

[davecotter]

MacBookPro15,1
macOS 10.14.6

here is the call stack:

note the high strangeness between frames 9 and 8.

the code shown is frame 9, within setGeometry(), so far so good.
looking at the line of code, frame 9 wants to call into QCocoaScreen::mapToNative(), reasonably.

However, when it MAKES the call, it ends up in QCocoaScreen::primaryScreen().

HUH?

It's my understanding that this happens when a library has been updated and the caller expects the update but the callee is still the OLD library. Not sure how this is possible.

any ideas NOW?

[SGaist]

Do you have several version of Qt installed ?
Maybe a warning at startup telling that there's something fishy with regard to the frameworks loaded ?

[davecotter]

Nope and nope

[SGaist]

What version of Qt ?

[davecotter]

4.10.0, and i did do a full uninstall-reinstall of both the "macOS" kit and the sources, to no avail.

[J.Hilk]

@davecotter said in fatal assert: The application's primary screen should always be in sync with the main display:

4.10.0

unlikely Qt 4 did not reach a 10s subversion 😉 What you likely told us, is is the QtCreator version. What @SGaist /we would like to know is the Qt Version used by your kit

[davecotter]

oh sorry hah!

5.13.1

-dave

[davecotter]

please, my project is dead in the water until i fix this. works fine on windows, just not on mac, where i do my dev work.

is this just a bug in the binaries for the macOS kit?

[davecotter]

update:

this is a macbook pro, 2018 model, which has switchable graphics card.

the problem ONLY occurs when using the low-power graphics card, the Intel UHD 630.
when i manually switch to the Radeon Pro 560X, all is well. or if i attach an external monitor (forcing the use of the Radeon) all is well.

would you agree this is a bug i should file?

[JKSH]

@davecotter said in fatal assert: The application's primary screen should always be in sync with the main display:

would you agree this is a bug i should file?

I agree that it would be great to find and fix the root cause of the crash.

You can certainly open a bug report. For it to be effective you need to help the Qt devs reproduce the issue reliably. Attach a minimal test case and provide clear and simple instructions to induce the crash.

please, my project is dead in the water until i fix this. works fine on windows, just not on mac, where i do my dev work.
In the meantime

Note that even if a Qt dev picks up your bug report and works on it, it will be a while before a fix is released.

In the meantime, you should apply a known workaround. It sounds like forcing the Radeon does the trick, yes?

Alternatively, what happens if you don't keep the QOpenGLWidget hidden in the beginning?

is this just a bug in the binaries for the macOS kit?

It's hard to say without a detailed investigation, I'm afraid.

[patrickkidd]

I have had the same problem when not using my external monitor with my MacBook. Super frustrating.

I was able to solve it by:

1. Re-connecting my external monitor
2. changing the external monitor using the "Arrangement" tab in the display system preferences to drag the white top-bar indicating the "primary display" from the external monitor to the MacBook monitor
3. launched the app in the MacBook monitor
4. unplugged my external monitor, launched it again
5. re-connected the external monitor and set the primary display in system prefs back to the external monitor.
6. Launched it again in the external monitor as primary display.

...or something like that. Not sure which step fixed it. Maybe there is some Qt pref that caches which monitor is primary for a certain combination of hardware the first time a Qt executable is executed, and maybe my workaround reset it. But now it works no matter how my system is set up.

Has to be a Qt bug, though primaryScreen() calls a macOS system call to get the primary display.

Cheers

[patrickkidd]

Looks like it has the potential to come back after my fix. The app fails on the following call after I have shown my main app window:

QCursor::pos()

Once removing that call from my code it crashes in another place, maybe more similar to what the first poster was seeing:

#0	0x0000000118075409 in QCocoaScreen::primaryScreen() at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/plugins/platforms/cocoa/qcocoascreen.mm:556
#1	0x000000011808d774 in QCocoaWindow::setCocoaGeometry(QRect const&) at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/plugins/platforms/cocoa/qcocoawindow.mm:293
#2	0x000000011808d281 in QCocoaWindow::setGeometry(QRect const&) at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/plugins/platforms/cocoa/qcocoawindow.mm:253
#3	0x000000010f324a07 in QWindow::resize(QSize const&) at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/gui/kernel/qwindow.cpp:1850
#4	0x00000001108d6456 in QWidgetPrivate::show_sys() at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/widgets/kernel/qwidget.cpp:8166
#5	0x00000001108d8b94 in QWidgetPrivate::show_helper() at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/widgets/kernel/qwidget.cpp:8096
#6	0x00000001108d9a3e in QWidgetPrivate::setVisible(bool) at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/widgets/kernel/qwidget.cpp:8398
#7	0x00000001108d964f in QWidget::setVisible(bool) at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/widgets/kernel/qwidget.cpp:8330
#8	0x00000001100a6702 in sipQMainWindow::setVisible(bool) at /Users/patrick/dev/vendor/sysroot-dev/build/PyQt5_gpl-5.12.2/QtWidgets/sipQtWidgetspart0.cpp:145076
#9	0x00000001108d887b in QWidget::show() at /Users/patrick/dev/vendor/sysroot-dev/build/qt-everywhere-src-5.13.1/qtbase/src/widgets/kernel/qwidget.cpp:7942

[patrickkidd]

I commented out the assertion in qcocoascreen.mm and things seem to work OK for now. I have no idea what other problems this will cause however so we should still seek a solution.

[davecotter]

i'm having trouble creating a minimal repro project. my main app (which is huge) repro's 100% of the time, and fails to repro 100% of the time if i have "graphics switching" turned off, or an external monitor plugged in.

can someone else repro this with a simple project?

i've filed this bug:
https://bugreports.qt.io/browse/QTBUG-78707

but i do not think it's enough to go on without a solid repro case

-dave

[JKSH]

@davecotter said in fatal assert: The application's primary screen should always be in sync with the main display:

i'm having trouble creating a minimal repro project. my main app (which is huge) repro's 100% of the time

What if you clone your main app and start deleting huge chunks of it? How small can you go before the issue disappears?

can someone else repro this with a simple project?

I don't have a macOS machine, sorry.

i've filed this bug:
https://bugreports.qt.io/browse/QTBUG-78707

+1

but i do not think it's enough to go on without a solid repro case

I think so too.

[davecotter]

What if you clone your main app and start deleting huge chunks of it?

my app is the size of photoshop†, it would take many weeks to do what you suggest.

perhaps @patrickkidd can repro?

-dave

† okay not LITERALLY the size of the PS code base, but there are dozens of dependencies, several dozen build scripts, hundreds of resources etc. there's just no practical way to take that route.

[davecotter]

i have filed this bug on it, if you care about this bug please "watch" it and/or vote for it