Data Abort Exception on ARM processor when the message WM_SETTINGCHANGE is processed

A Data Abort Exception can be caused on a Windows CE build by launching a Qt application and switching to the windows CE shell and performing any behavior which causes the OS to send out a WM_SETTINGCHANGE to our Qt App. For example, if you use Windows CE Start > Run > Browse and simply navigate around the file system, you can cause a recurring data abort in the Qt event handler.

Root cause for this issue is failure to protect against a null dereference (qt_desktopWidget) in qapplication_win.cpp on line 1509 :
http://www.qt.gitorious.org/qt-labs/widgets-ng/blobs/master/src/gui/kernel/qapplication_win.cpp#line1509

    case WM_SETTINGCHANGE:
#ifdef Q_WS_WINCE
        // CE SIP hide/show
        if (wParam == SPI_SETSIPINFO) {
            QResizeEvent re(QSize(0, 0), QSize(0, 0)); // Calculated by QDesktopWidget
            QApplication::sendEvent(qt_desktopWidget, &re);
            break;
        }
#endif

Could be changed to

    case WM_SETTINGCHANGE:
#ifdef Q_WS_WINCE
        // CE SIP hide/show
        if (qt_desktopWidget && wParam == SPI_SETSIPINFO) {
            QResizeEvent re(QSize(0, 0), QSize(0, 0)); // Calculated by QDesktopWidget
            QApplication::sendEvent(qt_desktopWidget, &re);
            break;
        }
#endif

You'll notice that in other locations within this file where qt_desktopWidget is used, it is checked to be non-null prior to use. Line 1509 doesn't do this behavior, so the pointer is passed down into the event handling system and eventually causes a data abort.

An end-user temporary work around is to call QApplication::desktop() immediately upon creating your QApplication such that this variable gets instantiated correctly (desktop() does this : http://www.qt.gitorious.org/qt-labs/widgets-ng/blobs/master/src/gui/kernel/qapplication.cpp#line3046).

QApplication *app = new QApplication(argc, argv);
app->desktop();
...