Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QGraphicsView::paintEvent crashes
Forum Updated to NodeBB v4.3 + New Features

QGraphicsView::paintEvent crashes

Scheduled Pinned Locked Moved Unsolved General and Desktop
17 Posts 4 Posters 5.6k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • ModelTechM Offline
    ModelTechM Offline
    ModelTech
    wrote on last edited by ModelTech
    #8

    The code I gave is called from the QWidget that contains the QGraphicsScene Scene, which has this QGraphicsObject Diagram as item. I have a destructor of the Widget that deletes Diagram, but perhaps that is not needed as it is a QObject?

    Edit: removing my destructor does not change a thing wrt the crashes...

    What are typical situations to use deleteLater instead of delete?

    kshegunovK 1 Reply Last reply
    0
    • ModelTechM ModelTech

      The code I gave is called from the QWidget that contains the QGraphicsScene Scene, which has this QGraphicsObject Diagram as item. I have a destructor of the Widget that deletes Diagram, but perhaps that is not needed as it is a QObject?

      Edit: removing my destructor does not change a thing wrt the crashes...

      What are typical situations to use deleteLater instead of delete?

      kshegunovK Offline
      kshegunovK Offline
      kshegunov
      Moderators
      wrote on last edited by
      #9

      @ModelTech said in QGraphicsView::paintEvent crashes:

      What are typical situations to use deleteLater instead of delete?

      In almost all situations it's preferred when dealing with QObject instances.

      On certain occasions, my complete application crashes on Linux and the trace given in the debugger does not show any of my code but only Qt code and the last human readable message is on QGraphicsView::paintEvent, see below.

      Eh, your stack trace is full of holes, sadly. Are you sure you're getting it from a debug build of your application?

      Read and abide by the Qt Code of Conduct

      ModelTechM 1 Reply Last reply
      1
      • kshegunovK kshegunov

        @ModelTech said in QGraphicsView::paintEvent crashes:

        What are typical situations to use deleteLater instead of delete?

        In almost all situations it's preferred when dealing with QObject instances.

        On certain occasions, my complete application crashes on Linux and the trace given in the debugger does not show any of my code but only Qt code and the last human readable message is on QGraphicsView::paintEvent, see below.

        Eh, your stack trace is full of holes, sadly. Are you sure you're getting it from a debug build of your application?

        ModelTechM Offline
        ModelTechM Offline
        ModelTech
        wrote on last edited by
        #10

        @kshegunov
        Thanks for the clarification on the deleteLater, I will change my code accordingly.

        The holes are indeed what I get from the debugger, showing assembly code when inspecting...

        kshegunovK 1 Reply Last reply
        0
        • ModelTechM ModelTech

          @kshegunov
          Thanks for the clarification on the deleteLater, I will change my code accordingly.

          The holes are indeed what I get from the debugger, showing assembly code when inspecting...

          kshegunovK Offline
          kshegunovK Offline
          kshegunov
          Moderators
          wrote on last edited by
          #11

          @ModelTech said in QGraphicsView::paintEvent crashes:

          The holes are indeed what I get from the debugger, showing assembly code when inspecting...

          Which just strengthens my suspicion you're debugging a release build, could you please check that?

          Read and abide by the Qt Code of Conduct

          1 Reply Last reply
          0
          • ModelTechM Offline
            ModelTechM Offline
            ModelTech
            wrote on last edited by ModelTech
            #12

            I am using a debug build, but I have investigated changing it to a release build, just to see the difference in error message. Conclusion: there is no difference...

            The fact that changing the build type was effective is seen from a difference in one warning that I get during compilation for the release build that I do not get for a debug build (it is about a variable that may be uninitialized, which in this case cannot occur in practice).

            1 Reply Last reply
            0
            • SGaistS Offline
              SGaistS Offline
              SGaist
              Lifetime Qt Champion
              wrote on last edited by
              #13

              Why can it not occur in practice ?

              Interested in AI ? www.idiap.ch
              Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

              ModelTechM 1 Reply Last reply
              0
              • SGaistS SGaist

                Why can it not occur in practice ?

                ModelTechM Offline
                ModelTechM Offline
                ModelTech
                wrote on last edited by ModelTech
                #14

                @SGaist Well, the considered code looks currently like this (where the warning is on variable Label). Perhaps I should change the third if into an else to avoid the warning. Anyway, changing this does not solve the crashing problem (I tried) as it is in a totally different/unrelated part of my code.

                if (Specification->isCSDFActor() || Specification->isDetector()) {
                    QLabel *Label;
                    if (Specification->isCSDFActor())
                        Label = new QLabel(tr("<strong>Phases</strong>"), this);
                    if (Specification->isDetector())
                        Label = new QLabel(tr("<strong>SubScenarios</strong>"), this);
                    QVBoxLayout *SubScenarioLayout = new QVBoxLayout;
                    SubScenarioLayout->addWidget(Label);
                }
                
                kshegunovK 1 Reply Last reply
                0
                • SGaistS Offline
                  SGaistS Offline
                  SGaist
                  Lifetime Qt Champion
                  wrote on last edited by SGaist
                  #15

                  With the code at hand then indeed, it should not happen.

                  To be on the clean and safe side, I'd rather write QLabel *Label = Q_NULLPTR; or QLabel *Label = nullptr;

                  Interested in AI ? www.idiap.ch
                  Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                  1 Reply Last reply
                  0
                  • ModelTechM ModelTech

                    @SGaist Well, the considered code looks currently like this (where the warning is on variable Label). Perhaps I should change the third if into an else to avoid the warning. Anyway, changing this does not solve the crashing problem (I tried) as it is in a totally different/unrelated part of my code.

                    if (Specification->isCSDFActor() || Specification->isDetector()) {
                        QLabel *Label;
                        if (Specification->isCSDFActor())
                            Label = new QLabel(tr("<strong>Phases</strong>"), this);
                        if (Specification->isDetector())
                            Label = new QLabel(tr("<strong>SubScenarios</strong>"), this);
                        QVBoxLayout *SubScenarioLayout = new QVBoxLayout;
                        SubScenarioLayout->addWidget(Label);
                    }
                    
                    kshegunovK Offline
                    kshegunovK Offline
                    kshegunov
                    Moderators
                    wrote on last edited by
                    #16

                    I realized that it may be system calls that are made in those stack holes. The most often crash I've encountered in the event loops is when an object is passed to Qt and it's subsequently deleted while events intended for it are still pending. I think you should check that this doesn't happen here..

                    Read and abide by the Qt Code of Conduct

                    1 Reply Last reply
                    0
                    • ModelTechM Offline
                      ModelTechM Offline
                      ModelTech
                      wrote on last edited by
                      #17

                      Ok, that sounds like a scenario that could be the case here. Is there an easy way to check whether events are pending for an object? Is there a way to clear the buffer holding events for an object that I could perhaps call before using delete/deleteLater?

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved