-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix gui tests stability #6619
Fix gui tests stability #6619
Conversation
retest this please |
The GUI tests still seem to fail on Windows, see here. The tag dialog test also fails on Linux - I will probably refactor that one soon. |
…o make it distinct from core_manager.start_tribler_core
…core_manager.should_quit_app_on_core_finished
…ager.core_connected
…/C++ object of has been deleted"
29df8ee
to
29af36e
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
retest this please |
@kozlovsky is this related to your PR? (build documentation job)
|
@devos50 it should not be related, but I'll investigate that. The previous error raw_output = bytes(self.core_process.readAllStandardOutput())
RuntimeError: wrapped C/C++ object of type QProcess has been deleted should be fixed now. |
In this PR, I rewrote the logic of
CoreManager
to fix the shutdown process sequence and make the logic ofCoreManager
easier to understand.With these changes, I was able to get completely stable GUI tests on my Windows machine. Previously I often got the following error (reported in #6039):
Now, this error is gone.
I don't know, will the PR fix crashes on Mac described in #6564 or not, but I hope it should also fix them as well.
The reason for the problem "wrapped C/C++ object of type CoreManager has been deleted" was emitting the
CoreManager.tribler_stopped
signal at the moment when the application had already quit, and Qt internal structures were partially destroyed. As it turns out, nobody actually uses this signal, so I removed it. If necessary, we can reintroduce it in the future, as now the improved logic of the CoreManager's shutdown process should track do we already callQApplication.quit()
or not and set the corresponding flagquitting_app
to True, preventing some actions at this stage.I rewrote the logic of the
CoreManager
shutdown to make it easier to understand. During this process, I noticed that we potentially do not always process errors on the Core shutdown. This is the previous logic of error handling:Note that if
CoreManager
was not in theshutting_down
state and the Core process suddenly finished with exit code 0, this situation was not processed. I don't know how often it can happen in practice, but in my opinion, if Core suddenly finished with exit code 0 when GUI did not expect it, it should be treated as an error, reported Sentry, and then GUI should stop. Before this PR, GUI hangs indefinitely in this situation.Now the logic looks the following way:
That is, now GUI handles any unexpected Core process termination.
I renamed
CoreManager
state flags because the previous names do not reflect the actual flag meaning. Also, I added some new flags to describe the CoreManager state completely.