Program doesn't completely quit
-
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).
@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.
-
When attaching with Visual Studio I get "Unable to attach to the process. Catastrophic failure." When using Qt Creator I get:
The process as it is hung now was run as an exe outside of both IDEs. Not sure if that's relevant.
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.
-
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?
-
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?
@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.
