Skip to content
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

Addon Manager: Refactor to use QNetworkAccessManager for (almost) everything #5412

Merged
merged 1 commit into from Jan 25, 2022

Conversation

chennes
Copy link
Member

@chennes chennes commented Jan 22, 2022

Migrate all network access to use a single global instance of QNetworkAccessManager (the recommended approach from Qt). This provides the following benefits:

  • Better interruption of long-running network accesses
  • Support for authenticated proxies
  • Automatic proxy credential caching
  • Automatic data caching
  • Better support for modern SSL connections
  • Non-blocking network access

This is purely refactoring: except for the added support for authenticated proxies, and better error messaging for a missing QtNetwork dependency, there are no user-visible changes. To test, simply ensure that you can continue to use the Addon Manager as usual.

If you are behind an authenticated proxy and can assist with debugging that part of the code, please post here or contact me on the FreeCAD forum.

@freecadci
Copy link

pipeline status for feature branch PR_5412. Pipeline 454040883 was triggered at d762024. All CI branches and pipelines.

To enable single-login authenticated proxy use, and simplified multi-threaded
network accesses, this commit adds a new wrapper around a QNetworkAccessManager
and includes a global instantiation of the class intended to exist for the
lifetime of the program. This instance can be used to enqueue any number of
network requests, which the manager will send out to the networking subsystem
in an appropriate manner.
@freecadci
Copy link

pipeline status for feature branch PR_5412. Pipeline 455232665 was triggered at db31c05. All CI branches and pipelines.

@chennes chennes merged commit 2b0a4dc into FreeCAD:master Jan 25, 2022
@marioalexis84
Copy link
Member

marioalexis84 commented Jan 26, 2022

@chennes with this commit I get random crashes when the program is closed.
I'm able to randomly reproduce the crash by making multiple attemps to open-close the program.
Example:
On 10 attemps to open and close the program, I get approx. 5 or 6 crashes.
I think this is related to this commit because I tried identical sequences with the previous commit and I can't reproduce the crashes.

Here the crash message:

Program received signal SIGSEGV, Segmentation fault.
#0  /usr/lib/libc.so.6(+0x3cda0) [0x7f35bcf8eda0]
#1  /usr/lib/libpython3.10.so.1.0(+0x15c56b) [0x7f35bf4f356b]
#2  /usr/lib/python3.10/site-packages/PySide2/QtCore.cpython-310-x86_64-linux-gnu.so(+0xab4e7) [0x7f358eea74e7]
#3  /usr/lib/libQt5Core.so.5(+0xe488c) [0x7f35bd54388c]
#4  /usr/lib/libpthread.so.0(+0x9259) [0x7f35be946259]
#5  /usr/lib/libc.so.6(clone+0x43) [0x7f35bd0505e3]
Program received signal SIGSEGV, Segmentation fault.
#0  /usr/lib/libc.so.6(+0x3cda0) [0x7f35bcf8eda0]
#1  0x7f35bd372986 in Shiboken::BindingManager::BindingManagerPrivate::releaseWrapper(void*, SbkObject*) from /usr/lib/libshiboken2.cpython-310-x86_64-linux-gnu.so.5.15+0x16
#2  0x7f35bd375f2a in Shiboken::BindingManager::releaseWrapper(SbkObject*) from /usr/lib/libshiboken2.cpython-310-x86_64-linux-gnu.so.5.15+0x8a
#3  /usr/lib/libshiboken2.cpython-310-x86_64-linux-gnu.so.5.15(+0x28d0b) [0x7f35bd379d0b]
#4  /usr/lib/libshiboken2.cpython-310-x86_64-linux-gnu.so.5.15(+0x18544) [0x7f35bd369544]
#5  /usr/lib/libpython3.10.so.1.0(+0x1f642b) [0x7f35bf58d42b]
#6  /usr/lib/libpython3.10.so.1.0(+0x1b3960) [0x7f35bf54a960]
#7  /usr/lib/libpython3.10.so.1.0(+0x12c25a) [0x7f35bf4c325a]
#8  /usr/lib/libpython3.10.so.1.0(+0x21fc2c) [0x7f35bf5b6c2c]
#9  /usr/lib/libpython3.10.so.1.0(+0x21f123) [0x7f35bf5b6123]
#10  /usr/lib/libpython3.10.so.1.0(Py_FinalizeEx+0x13d) [0x7f35bf5b378d]
#11  0x7f35bfe2dca5 in Base::InterpreterSingleton::finalize() /lib/libFreeCADBase.so+0x21

@luzpaz
Copy link
Contributor

luzpaz commented Jan 26, 2022

@marioalexis84 please crash output in code tags since the # by itself will reference other PRs

@chennes
Copy link
Member Author

chennes commented Jan 26, 2022

Thanks for the report, I'll look into it.

@marioalexis84
Copy link
Member

Seems to be solved by f045a0b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants