Qt World Summit: Submit your Presentation

Setting value to QProgressBar causes program to crash

  • I designed a multithreaded video-recording program but it sometimes crashes and I need help to figure out why.

    My threads (which extends QThread) emit a signal (with an int identifying them and a double indicating their progress) which is connected to a slot in the MainWindow. The slot average the progress of the different threads and update a QProgressBar. I tried to catch the errors but it doesn't work...


    void MainWindow::captureProgressHandler(int i_Thread, double d_Progress) {
            v_d_Progress[i_Thread] = d_Progress;
            double d_Average = 0.0;
            for (int i = 0; i < v_d_Progress.size(); i++) {
                d_Average += v_d_Progress[i];
            d_Average /= v_d_Progress.size();
            d_Average *= 100;
            qInfo() << "Average progress:" << (int) d_Average << "%.";
            if (qpb_Progress->value() != (int) d_Average) {
                try {
                    qpb_Progress->setValue((int) d_Average);
                } catch (...) { // Does not work 
                    qInfo() << "Error!";


    QWidget::repaint: Recursive repaint detected
    The program has unexpectedly finished.

  • Lifetime Qt Champion

    qpb_Progress is a member of MainWindow ?

    captureProgressHandler is the slot that all threads signal is connected to ?

  • Lifetime Qt Champion


    Are you doing any custom painting ? Call update ?

  • @bs55
    Are you sure your application is crashing in this function??

  • @mrjj Yes qpb_Progress is a member of the MainWindow and captureProgressHandler(int i_Thread, double d_Progress) is the slot connected to the thread's signal.

  • @Tirupathi-Korla Yes because when I comment this line

    // qpb_Progress->setValue((int) d_Average); 

    the program doen not crash...

  • Lifetime Qt Champion

    Is qpb_Progress initialised properly ?

    Can you show the stack trace ?

  • @SGaist The QProgressBar is initialized by this line:

    qpb_Progress = new QProgressBar(this);

    The stack trace is as follows:

    Thread # 1 :  50 %.
    Thread # 0 :  50 %.
    QWidget::repaint: Recursive repaint detected
    Average progress: 25 %.
    The program has unexpectedly finished.
    The process was ended forcefully.
    /home/remi/Documents/Internship/MyProjects/build-SpinnakerSandboxQt3-Desktop-Debug/SpinnakerSandboxQt crashed.

    It does not occur when I use only one camera (and therefore one thread) so my guess is that the function is executed twice simutanously and that it causes a conflict when the two instance try to access the QProgressBar at the same time...

  • Lifetime Qt Champion

    Are you trying to update GUI elements directly your threads ?

  • @SGaist No the thread emit a signal that is connected to a slot in the MainWindow...

  • Lifetime Qt Champion

    I tried with 2 worker objets to have them bombard a ProgressBar
    in mainwindow but i couldn't get the same error.

  • @mrjj Maybe the error only occurs on Linux.
    Considering the number of cameras and their framerate it will be called up to 2440 times per second (that's one call every 0.41 milliseconds). Maybe Qt isn't up for the task...

  • Lifetime Qt Champion

    hard to say as im not sure what give the
    "Recursive repaint detected"
    it does sound like a paint is in progress while new one started but
    signals should prevent that. ( i tried with 6 threads but still no error)

    Qt uses native tasks so if its not fast enough, you might need other design to reach such speeds.

  • Lifetime Qt Champion

    You do realise that most screens have at most a 60fps refresh rate while the human eyes is already fooled at 24 ? So having a 2440 Hz refresh rate is useless and from the looks of it you are even overloading your application with that.

  • @SGaist You're right, the function to register the progress of each threads will be called 2440 times per second but I should create another function just to refresh the progress bar that would be called less often...

Log in to reply