Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt
  • Unsolved
Collapse
qtws26_logo

The Qt Event of the Year: Qt World Summit 2026

Save Your Spot >
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. The program has unexpectedly finished.
Qt 6.12 LTS is out! See what's new in the release blog

The program has unexpectedly finished.

Scheduled Pinned Locked Moved Solved General and Desktop
13 Posts 4 Posters 5.7k Views 2 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.
  • O Offline
    O Offline
    ofmrew
    wrote on last edited by
    #1

    I have a very simple program that finds the intersection of two QLineF and draws a circle around the intersection point. It will compile , but when I try to run it I get the message "The program has unexpectedly finished." and the window closes. The very strange thing is that if I try running the program again and again I will work, sometime on the third try or fifth try. Has any one seen this. It is Qt5.9 on a 64-bit Mint Linux.

    I can post the program if that is required. Any ideas?

    Thanks

    O 1 Reply Last reply
    0
    • O ofmrew

      I have a very simple program that finds the intersection of two QLineF and draws a circle around the intersection point. It will compile , but when I try to run it I get the message "The program has unexpectedly finished." and the window closes. The very strange thing is that if I try running the program again and again I will work, sometime on the third try or fifth try. Has any one seen this. It is Qt5.9 on a 64-bit Mint Linux.

      I can post the program if that is required. Any ideas?

      Thanks

      O Offline
      O Offline
      ofmrew
      wrote on last edited by
      #2

      @ofmrew Let me add that when it works it fails when I move the mouse. Does that help?

      1 Reply Last reply
      0
      • O Offline
        O Offline
        ofmrew
        wrote on last edited by
        #3

        I reopened this because I am at an impasse. I ran example2 in debug mode and got to the end; however, in normal run it just exits.

        #ifndef MYCANVAS_H
        #define MYCANVAS_H

        #include <QWidget>
        #include <QPainter>
        #include <QLineF>

        class MyCanvas : public QWidget
        {
        Q_OBJECT
        public:
        explicit MyCanvas(QWidget *parent = nullptr);
        void paintEvent(QPaintEvent *e);

        int exampleType;
        QLineF lineA;
        QLineF lineB;
        QLineF line0;
        QLineF line1;
        QLineF line2;
        QLineF line3;
        QLineF line4;
        QLineF line5;
        QVector<QLineF> poly;
        QPointF *intersectionPointA;
        QLineF::IntersectType intersectionTypeA;
        QPointF *intersectionPoint;
        QPointF *intersectionPointPoly;
        QLineF::IntersectType intersectionType;
        

        signals:

        public slots:
        void intersectionExample1();
        void intersectionExample2();

        };

        #endif // MYCANVAS_H

        MainWindow::MainWindow(QWidget *parent) :
        QMainWindow(parent),
        ui(new Ui::MainWindow)
        {
        ui->setupUi(this);
        ui->canvas->setBackgroundRole(QPalette::Base);
        connect(ui->example1, &QPushButton::clicked, ui->canvas, &MyCanvas::intersectionExample1);
        connect(ui->example2, &QPushButton::clicked, ui->canvas, &MyCanvas::intersectionExample2);
        }

        #include "mycanvas.h"
        #include <QDebug>

        MyCanvas::MyCanvas(QWidget *parent) : QWidget(parent)
        {

        }

        void MyCanvas::paintEvent(QPaintEvent *e)
        {
        QPainter p(this);
        if (exampleType == 1){
        qDebug() << " In PaintEvent" << *intersectionPointA;
        p.drawLine(lineA);
        p.drawLine(lineB);
        if (intersectionTypeA == QLineF::BoundedIntersection){
        p.drawEllipse(*intersectionPointA, 5, 5);
        }
        return;
        }
        if (exampleType == 2){
        qDebug() << " In 2";
        p.drawLine(line0);
        p.setPen(QColor(Qt::red));
        p.drawLines(poly);
        p.drawEllipse(*intersectionPointPoly, 5, 5);
        return;
        }
        }

        void MyCanvas::intersectionExample1()
        {
        exampleType = 1;
        lineA = QLineF(QPointF(0.0, 0.0), QPointF(600.0, 800.0));
        lineB = QLineF(QPointF(500.0, 100.0), QPointF(100.0, 500.0));
        qDebug() << line1 << " " << line2;
        intersectionTypeA = lineA.intersect(lineB, intersectionPointA);
        qDebug() << intersectionTypeA << " " << *intersectionPointA << " Got Past Intersection";
        this->update();
        return;
        }

        void MyCanvas::intersectionExample2()
        {
        exampleType = 2;
        line0 = QLineF(QPointF(100.0, 100.0), QPointF(500.0, 500.0));

        line1 = QLineF(QPointF(500.0, 100.0), QPointF(450.0, 250.0));
        line2 = QLineF(QPointF(450.0, 250.0), QPointF(325.0, 300.0));
        line3 = QLineF(QPointF(325.0, 300.0), QPointF(250.0, 300.0));
        line4 = QLineF(QPointF(250.0, 300.0), QPointF(200.0, 250.0));
        line5 = QLineF(QPointF(200.0, 250.0), QPointF(100.0, 150.0));
        poly << line5 << line4 << line3 << line2 << line1;
        qDebug() << poly;
        for (int i = 0; i < poly.count(); i++){
            QLineF l = poly.at(i);
            qDebug() << i << " " << line0 << " " << l;
            intersectionType = line0.intersect(l, intersectionPoint);
            qDebug() << i << intersectionType; //<< "  " << *intersectionPoint;
            if (intersectionType == QLineF::BoundedIntersection){
                qDebug() << "In if";// << *intersectionPoint;
                intersectionPointPoly = new QPointF(*intersectionPoint);
                qDebug() << " Past new";
            //qDebug() << i << "  " << intersectionType << "  " << *intersectionPoint;
            }
        }
        this->update();
        

        }

        It is probably something stupid, but I do not see the problem. Any help will be greatly appreciated.

        Thanks

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

          Hi,

          Why are you using pointers for these QPoint variables ?

          From a quick look, you didn't initialyse them.

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

          O 1 Reply Last reply
          0
          • SGaistS SGaist

            Hi,

            Why are you using pointers for these QPoint variables ?

            From a quick look, you didn't initialyse them.

            O Offline
            O Offline
            ofmrew
            wrote on last edited by
            #5

            @SGaist

            QLineF::intersect(const QLineF &line, QPointF *intersectionPoint) const.

            I set them up as instance variables (data members) so I could assign a values in one method without having them lost before they could be used in paintEvent().

            If the is a better way I am open to suggestions.

            jsulmJ 1 Reply Last reply
            0
            • O ofmrew

              @SGaist

              QLineF::intersect(const QLineF &line, QPointF *intersectionPoint) const.

              I set them up as instance variables (data members) so I could assign a values in one method without having them lost before they could be used in paintEvent().

              If the is a better way I am open to suggestions.

              jsulmJ Offline
              jsulmJ Offline
              jsulm
              Lifetime Qt Champion
              wrote on last edited by
              #6

              @ofmrew

              class MyCanvas : public QWidget
              {
              Q_OBJECT
              public:
              explicit MyCanvas(QWidget *parent = nullptr);
              void paintEvent(QPaintEvent *e);
              
              int exampleType;
              QLineF lineA;
              QLineF lineB;
              QLineF line0;
              QLineF line1;
              QLineF line2;
              QLineF line3;
              QLineF line4;
              QLineF line5;
              QVector<QLineF> poly;
              QPointF *intersectionPointA;
              QLineF::IntersectType intersectionTypeA;
              QPointF *intersectionPoint;
              QPointF *intersectionPointPoly;
              QLineF::IntersectType intersectionType;
              

              What @SGaist means: why are intersectionPointA, intersectionPoint, intersectionPointPoly pointers? Just do them normal instance variables. Nothing will be lost.

              QLineF::intersect(const QLineF &line, QPointF *intersectionPoint) const.
              

              What is the problem with that? Just get pointers to your instance variables if you call it:

              point::intersect(line, &intersectionPoint);
              

              https://forum.qt.io/topic/113070/qt-code-of-conduct

              O 1 Reply Last reply
              1
              • jsulmJ jsulm

                @ofmrew

                class MyCanvas : public QWidget
                {
                Q_OBJECT
                public:
                explicit MyCanvas(QWidget *parent = nullptr);
                void paintEvent(QPaintEvent *e);
                
                int exampleType;
                QLineF lineA;
                QLineF lineB;
                QLineF line0;
                QLineF line1;
                QLineF line2;
                QLineF line3;
                QLineF line4;
                QLineF line5;
                QVector<QLineF> poly;
                QPointF *intersectionPointA;
                QLineF::IntersectType intersectionTypeA;
                QPointF *intersectionPoint;
                QPointF *intersectionPointPoly;
                QLineF::IntersectType intersectionType;
                

                What @SGaist means: why are intersectionPointA, intersectionPoint, intersectionPointPoly pointers? Just do them normal instance variables. Nothing will be lost.

                QLineF::intersect(const QLineF &line, QPointF *intersectionPoint) const.
                

                What is the problem with that? Just get pointers to your instance variables if you call it:

                point::intersect(line, &intersectionPoint);
                
                O Offline
                O Offline
                ofmrew
                wrote on last edited by
                #7

                @jsulm
                I changed the three pointer variables as suggested and it worked. Also, I prefer not using pointers unless absolutely necessary. There is, however, something that that change does not explain; namely, why after some number of failures it just worked. I know the trick of deleting the build directory, is this something of that nature? I hate inconsistency: a program should produce the same result every time it is executed with the same input. That is why the trick with the build library bothers me.

                I wrote a closest point on a line segment to a point method which returned a structure that contained three variables; whether it was valid based on a distance parameter, whether it was an end point of the segment and the point. That seems a much nicer way to handle something like the line segments intersection. But that is me.

                Thanks to both.

                VRoninV 1 Reply Last reply
                0
                • O ofmrew

                  @jsulm
                  I changed the three pointer variables as suggested and it worked. Also, I prefer not using pointers unless absolutely necessary. There is, however, something that that change does not explain; namely, why after some number of failures it just worked. I know the trick of deleting the build directory, is this something of that nature? I hate inconsistency: a program should produce the same result every time it is executed with the same input. That is why the trick with the build library bothers me.

                  I wrote a closest point on a line segment to a point method which returned a structure that contained three variables; whether it was valid based on a distance parameter, whether it was an end point of the segment and the point. That seems a much nicer way to handle something like the line segments intersection. But that is me.

                  Thanks to both.

                  VRoninV Offline
                  VRoninV Offline
                  VRonin
                  wrote on last edited by
                  #8

                  @ofmrew said in The program has unexpectedly finished.:

                  a program should produce the same result every time it is executed with the same input.

                  Not true if you have undefined behaviour. Usually this translates in "the state of your RAM is an input" and the state of your RAM is (almost) never the same when you run the program again

                  "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                  ~Napoleon Bonaparte

                  On a crusade to banish setIndexWidget() from the holy land of Qt

                  O 1 Reply Last reply
                  2
                  • VRoninV VRonin

                    @ofmrew said in The program has unexpectedly finished.:

                    a program should produce the same result every time it is executed with the same input.

                    Not true if you have undefined behaviour. Usually this translates in "the state of your RAM is an input" and the state of your RAM is (almost) never the same when you run the program again

                    O Offline
                    O Offline
                    ofmrew
                    wrote on last edited by
                    #9

                    @VRonin
                    I agree that RAM is inconsistent (except with some old systems that zeroed memory when a program was loaded), but a correct program never depends of the state of uninitialized memory. Are you saying that Qt caches some program data memory and reuses it or was it because I allocated the pointer but did not initialize the object to which it pointed? C++ and Qt do a lot "stuff" under the covers and I what to learn what not to do.

                    VRoninV 1 Reply Last reply
                    0
                    • O ofmrew

                      @VRonin
                      I agree that RAM is inconsistent (except with some old systems that zeroed memory when a program was loaded), but a correct program never depends of the state of uninitialized memory. Are you saying that Qt caches some program data memory and reuses it or was it because I allocated the pointer but did not initialize the object to which it pointed? C++ and Qt do a lot "stuff" under the covers and I what to learn what not to do.

                      VRoninV Offline
                      VRoninV Offline
                      VRonin
                      wrote on last edited by
                      #10

                      @ofmrew said in The program has unexpectedly finished.:

                      but a correct program never depends of the state of uninitialized memory

                      You exactly got the point there. A correct program never does. A program that uses dangling pointers (as yours above) does, by definition, depend of the state of uninitialized memory

                      "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                      ~Napoleon Bonaparte

                      On a crusade to banish setIndexWidget() from the holy land of Qt

                      O 1 Reply Last reply
                      2
                      • VRoninV VRonin

                        @ofmrew said in The program has unexpectedly finished.:

                        but a correct program never depends of the state of uninitialized memory

                        You exactly got the point there. A correct program never does. A program that uses dangling pointers (as yours above) does, by definition, depend of the state of uninitialized memory

                        O Offline
                        O Offline
                        ofmrew
                        wrote on last edited by
                        #11

                        @VRonin
                        Question. If I define a pointer variable, but never use it ( assignment or reference) why would it cause a problem? The definition should only allocate the memory for the pointer. I believe that it was in one of my qDebug statements that caused the problem, adding the example 2 code. I got misled by the method using a pointer and down a lot of rabbit holes. Thanks.

                        1 Reply Last reply
                        0
                        • VRoninV Offline
                          VRoninV Offline
                          VRonin
                          wrote on last edited by VRonin
                          #12

                          I think the confusion is arising from how Qt handles output arguments. To highlight the fact that certain arguments will be changed internally by the function, Qt uses pointer arguments instead of non-const references. It's a (wise imho) implementation choice. The second argument to QLineF::intersect is one of these cases. You can check here what the function is doing with the intersectionPoint argument. It's assigning to it.

                          So passing a dangling pointer to that method (as you are) is equivalent to assigning to it

                          "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                          ~Napoleon Bonaparte

                          On a crusade to banish setIndexWidget() from the holy land of Qt

                          O 1 Reply Last reply
                          1
                          • VRoninV VRonin

                            I think the confusion is arising from how Qt handles output arguments. To highlight the fact that certain arguments will be changed internally by the function, Qt uses pointer arguments instead of non-const references. It's a (wise imho) implementation choice. The second argument to QLineF::intersect is one of these cases. You can check here what the function is doing with the intersectionPoint argument. It's assigning to it.

                            So passing a dangling pointer to that method (as you are) is equivalent to assigning to it

                            O Offline
                            O Offline
                            ofmrew
                            wrote on last edited by
                            #13

                            @VRonin
                            ipmlementation is based on Graphics Gems III's "Faster Line Segment Intersection"

                            I find it interesting that this comes from the same set of books I used extensively in the early 1990 and probably used this routine. (I was developing an object oriented GIS-Facilities Manage System for utilities using Smalltalk that was base on interactive graphics, when most graphics systems were batch. In did interactively what others did with a clean and build. I worked extremely well on a 386 machine running OS/2.)

                            Are all the Qt classes on that web site? It does as I thought that it would by assigning the value. Again, my mistake was an errant qDebug using the dangling pointer. I need to go back to the C++ literature to look at assignment. Is it a replacement of pointers or is it copying the variables of the new point replacing the existing ones--which would be a problem if the pointer was not initialized.

                            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
                            • Unsolved