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. Program doesn't completely quit

Program doesn't completely quit

Scheduled Pinned Locked Moved Unsolved General and Desktop
25 Posts 5 Posters 6.7k Views
  • 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.
  • C Offline
    C Offline
    Crag_Hack
    wrote on last edited by
    #15

    I've used a small spectrum of win API functions. Some requiring COM.

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

      Did you check whether some of them needed to free some resource to properly stop ?

      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
      • C Offline
        C Offline
        Crag_Hack
        wrote on last edited by
        #17

        I read the documentation thoroughly for all the functions. Weird thing is the intermittent nature of what's occurring and also that is happens after not having done any worker object work.

        1 Reply Last reply
        0
        • C Crag_Hack

          I have an interesting situation with my Qt program... in the installer I made with NSIS I have a page that detects if the program is running and if so prompts the user to close the program. Most of the time things proceed just fine however sometimes on my laptop the installer will detect the program running even though I quit it already. Nothing shows up in task manager however when I run tasklist from the command prompt after having quit the program I see:

          C:\Users\Owner>tasklist /FI "IMAGENAME eq ReplicatorNew.exe"
          
          Image Name                     PID Session Name        Session#    Mem Usage
          ========================= ======== ================ =========== ============
          ReplicatorNew.exe             8256 Console                    1         28 K
          

          If I run the program again I see:

          Image Name                     PID Session Name        Session#    Mem Usage
          ========================= ======== ================ =========== ============
          ReplicatorNew.exe             8256 Console                    1         28 K
          ReplicatorNew.exe             3040 Console                    1     50,940 K
          

          So something is sticking around after closing the program. Any ideas what's going on here? Thanks.

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

          Get a stack trace from those processes that hang and post it here. (e.g. as described here)
          That's the best you can do to trace it, at least that is if it doesn't already hang in the debugger ...

          PS.
          Show us (parts) of your Worker class, as I see trouble brewing here.

          This:

          worker->stop(); //sets boolean cancel to true to let worker finish its work
          

          and this

          workerThread->quit();
          

          very rarely go hand in hand.

          Read and abide by the Qt Code of Conduct

          1 Reply Last reply
          4
          • C Offline
            C Offline
            Crag_Hack
            wrote on last edited by
            #19

            Since JKSH said he's out of ideas I opened another thread over at MSDN. See here. We ran process explorer and it showed the process as suspended. Also when trying to kill in process explorer we get access denied. Here is the threads info (no stack trace available). Also the process is not ReplicatorNew.exe it's Buddha Backup x64.exe (I was hesitant to get my name out there but concluded it doesn't' really matter).

            0_1532290551431_stacktrace.png

            kshegunovK 1 Reply Last reply
            0
            • C Offline
              C Offline
              Crag_Hack
              wrote on last edited by Crag_Hack
              #20

              Here's the requested code with the previous code as well. Edited for brevity.

              void ReplicatorMainScreen::closeEvent(QCloseEvent *event)
              {
                  emit stopWork();
                  event->accept();
              }
              
              void ReplicatorMainScreen::setupBackend(Replicator *rep)
              {
                  connect(ui->backupSelectedButton,SIGNAL(clicked(bool)),rep,SLOT(selectedBackup()));
                  connect(this,SIGNAL(stopWork()),rep,SLOT(stopWork()));
                  connect(ui->cancelButton,SIGNAL(clicked(bool)),rep,SLOT(cancelBackup()));
              }
              
              void Replicator::cancelBackup()
              {
                  if (isBusy)
                      worker->stop();
              }
              
              void Replicator::stopWork()
              {
                  quitting = true;
                  if (isBusy)
                      worker->stop(); //sets boolean cancel to true to let worker finish its work
              }
              
              void Worker::stop() { cancel = true; } // cancel is std::atomic_bool
              
              void Replicator::selectedBackup()
              {
                  isBusy = true;
                  emit backup(jobList,simpleJobs);
              }
              
              void Worker::backup(QList<BackupJob> passJobs, QList<BackupJob> passSimpleJobs)
              {
                  jobs = passJobs;
                  simpleJobs = passSimpleJobs;
                  startJobScans(); //these check for cancel condition and abort if true
                  startJobBackups(); // this too
                  emit backupFinished(JobType::Normal, cancel, errorsFound);
              }
              
              void Replicator::backupDone()
              {
                  isBusy = false;
              }
              
              Replicator::~Replicator()
              {
                  workerThread->quit();
                  workerThread->wait();
              }
              
              Replicator::Replicator(QWidget *parent) :
                  QWidget(parent)
              {
                  workerThread = new QThread(this);
                  workerThread->start();
                  worker = new Worker;
                  worker->moveToThread(workerThread);
                  mainScreen = new ReplicatorMainScreen;
                  setupWorker();
                  mainScreen->setupBackend(this);
              }
              
              void Replicator::setupWorker()
              {
                  connect(this, SIGNAL(backup(QList<BackupJob>,QList<BackupJob>)), worker, SLOT(backup(QList<BackupJob>,QList<BackupJob>)));
                  connect(worker, SIGNAL(backupFinished(JobType,bool,bool)), this, SLOT(backupDone(JobType,bool,bool)));
                  connect(workerThread, SIGNAL(finished()), worker, SLOT(deleteLater()));
              }
              
              1 Reply Last reply
              0
              • C Crag_Hack

                Since JKSH said he's out of ideas I opened another thread over at MSDN. See here. We ran process explorer and it showed the process as suspended. Also when trying to kill in process explorer we get access denied. Here is the threads info (no stack trace available). Also the process is not ReplicatorNew.exe it's Buddha Backup x64.exe (I was hesitant to get my name out there but concluded it doesn't' really matter).

                0_1532290551431_stacktrace.png

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

                @Crag_Hack said in Program doesn't completely quit:

                Here is the threads info (no stack trace available).

                Attach the debugger and do an interrupt after that (in the debug menu). Work with a debug build so you get unoptimized code and you can trace the stack.

                Read and abide by the Qt Code of Conduct

                1 Reply Last reply
                0
                • C Offline
                  C Offline
                  Crag_Hack
                  wrote on last edited by
                  #22

                  When attaching with Visual Studio I get "Unable to attach to the process. Catastrophic failure." When using Qt Creator I get:

                  0_1532293994392_qc.png

                  The process as it is hung now was run as an exe outside of both IDEs. Not sure if that's relevant.

                  kshegunovK 1 Reply Last reply
                  0
                  • C Crag_Hack

                    When attaching with Visual Studio I get "Unable to attach to the process. Catastrophic failure." When using Qt Creator I get:

                    0_1532293994392_qc.png

                    The process as it is hung now was run as an exe outside of both IDEs. Not sure if that's relevant.

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

                    Did you stop all the antivirus programs? Antivirus software often interferes with debugging and some of it even run services on top of custom drivers that hook all over the OS in all kinds of nasty ways. Disable automatic antivirus, disable its services reboot and reproduce, then try to attach the debugger.

                    Read and abide by the Qt Code of Conduct

                    1 Reply Last reply
                    0
                    • C Offline
                      C Offline
                      Crag_Hack
                      wrote on last edited by
                      #24

                      Update - I ran the program ~196 times total, evenly distributed between running a backup and not running a backup and also between running the original exe, running with my copy protection wrapper, and running with the NSIS installer. It didn't exhibit the erratic behavior not even once. One detail though is I am using QtSingleApplication and also QtLockedFile. I also found this page which attributes similar behavior to buggy drivers not handling IO well. Are QtSingleApplication and QtLockedFile mature enough to be bug free? I show having used version 2.6 according to readme.txt in my local repository, which is the same version as on github according to readme.txt.

                      Also @kshegunov the worker->stop() just sets the boolean cancel to true so the worker object in the worker thread can read the boolean and halt it's operations, return to the event loop, and in the case that workerThread->quit() is called the event loop picks up the event and quits. Should be safe right?

                      JKSHJ 1 Reply Last reply
                      0
                      • C Crag_Hack

                        Update - I ran the program ~196 times total, evenly distributed between running a backup and not running a backup and also between running the original exe, running with my copy protection wrapper, and running with the NSIS installer. It didn't exhibit the erratic behavior not even once. One detail though is I am using QtSingleApplication and also QtLockedFile. I also found this page which attributes similar behavior to buggy drivers not handling IO well. Are QtSingleApplication and QtLockedFile mature enough to be bug free? I show having used version 2.6 according to readme.txt in my local repository, which is the same version as on github according to readme.txt.

                        Also @kshegunov the worker->stop() just sets the boolean cancel to true so the worker object in the worker thread can read the boolean and halt it's operations, return to the event loop, and in the case that workerThread->quit() is called the event loop picks up the event and quits. Should be safe right?

                        JKSHJ Offline
                        JKSHJ Offline
                        JKSH
                        Moderators
                        wrote on last edited by
                        #25

                        @Crag_Hack said in Program doesn't completely quit:

                        Are QtSingleApplication and QtLockedFile mature enough to be bug free? I show having used version 2.6 according to readme.txt in my local repository, which is the same version as on github according to readme.txt.

                        I don't know about their maturity, but those classes have not been maintained for many years.

                        Qt 5 has a new class called QLockFile (http://doc.qt.io/qt-5/qlockfile.html ) -- its API is not a drop-in replacement for QtLockFile, however. There is no modern equivalent for QtSingleApplication.

                        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                        1 Reply Last reply
                        1

                        • Login

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