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

Patch - Change order of declaration of QScopedPointer's in q_supportsElementIndexUint



    • Type: Bug
    • Status: Open
    • Priority: P1: Critical
    • Resolution: Unresolved
    • Affects Version/s: 5.12
    • Fix Version/s: None
    • Component/s: Quick: 2D Renderer
    • Labels:
    • Environment:
      Yocto thud based image, QT 5.12.2, Linux 4.19.13


      I've been having a crash (segfault) in a project using QML. The crash happens in an embedded machine running a yocto generated image, using eglfs. The embedded machine is a regular PC based on an Intel processor, running QT 5.12.2 and Linux 4.19.13. I was able to determine that using the QML type ShapePath with a non-transparent fillColor property triggered the segfault, but unfortunately I couln't reproduce it outside the target machine, not even in a fedora machine running the same library version and under eglfs.

      Anyway, by debugging the application directly in the target machine, I could pinpoint the source of the problem:


              if (!elementIndexUintChecked) {
                  elementIndexUintChecked = true;
                  QOpenGLContext *context = QOpenGLContext::currentContext();
                  QScopedPointer<QOpenGLContext> dummyContext;
                  QScopedPointer<QOffscreenSurface> dummySurface;
                  bool ok = true;
                  if (!context) {
                      dummyContext.reset(new QOpenGLContext);
                      context = dummyContext.data();
                      dummySurface.reset(new QOffscreenSurface);
                      ok = context->makeCurrent(dummySurface.data());
                  if (ok) {
                      elementIndexUint = static_cast<QOpenGLExtensions *>(context->functions())->hasOpenGLExtension(

      This code snippet is from the file src/quickshapes/qquickshapegenericrenderer.cpp in qtdeclarative. The problem, I think, is that the smart pointers dummyContext and dummySurface are declared in the incorrect order. If QOpenGLContext::currentContext() returns nullptr, then dummyContext is destroyed after dummySurface is destroyed, so during the destruction it is holding a pointer to an invalid object. I'm not sure if this is safe or not, since I don't fully understand what happens during the destruction of a QOpenGLContext, but what I know is that changing the order of declaration fixes the crash. Perhaps someone with better understanding can validate this. In any case, I'm submitting a patch that does just that.

      If anything else is needed (backtraces, core dumps, versions) please ask.



        No reviews matched the request. Check your Options in the drop-down menu of this sections header.



            • Assignee:
              janichol Andy Nichols
              aesteve Aitor Esteve Alvarado
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created:

                Gerrit Reviews

                There are no open Gerrit changes