Q*Application: fix UB caused by accessing QGuiApplication from QCoreApplication ctor

As reported by ubsan:

  src/gui/kernel/qplatformintegration.cpp:463:10: runtime error: downcast of address 0x7ffdc2942490 which does not point to an object of type 'QGuiApplication'
  0x7ffdc2942490: note: object is of type 'QCoreApplication'

  src/gui/kernel/qplatformintegration.cpp:466:14: runtime error: downcast of address 0x7ffdc2942490 which does not point to an object of type 'QGuiApplication'
  0x7ffdc2942490: note: object is of type 'QCoreApplication'

  src/gui/kernel/qplatformintegration.cpp:466:43: runtime error: member call on address 0x7ffdc2942490 which does not point to an object of type 'QGuiApplication'
  0x7ffdc2942490: note: object is of type 'QCoreApplication'

to name just a few which are reported when running gui and widget
auto-tests; there're definitely more where these came from.

This is caused by QCoreApplication::init() being called from the
QCoreApplication ctor, calling virtual functions on Q*AppPrivate,
which happen to attempt, in this case, to emit QGuiApp signals.
At that point in time, the QGuiApplication ctor has not entered
the constructor body, ergo the object is still a QCoreApplication,
and calling the signal, as a member function on the derived class,
invokes UB.

Fix by cleaning up the wild mix of initialization functions used in
this hierarchy. The cleanup restores the

  1. Q*ApplicationPrivate::Q*ApplicationPrivate()
  2. Q*ApplicationPrivate::init(), calling each base class'
     init() as the first thing

two-stage construction pattern commonly used elsewhere in Qt to make
sure that the public class' object is fully constructed by the time
each level's Private::init() is called.

Change-Id: I290402b3232315d7ed687c97e740bfbdbd3ecd1a
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>

0 files changed, 0 insertions, 0 deletions