When a setting is set it locks the Settings mutex and emits a signal for that
setting. If a slot is connected to that signal and lives on the same thread as
Settings, it is executed immediately with the Settings mutex still locked. That
slot can then lock a series of other mutexes. During this time another thread
can lock a mutex and then try to read settings, which will cause a deadlock due
to the opposite order of multiple mutex locking. By always emitting signals
after unlocking the Settings mutex, we avoid holding the Settings mutex while
executing slots.
Fix#6218
https://github.com/qTox/qTox/pull/5866 both updated our travis xcode version,
and also added the dots in 8e597ed736. When macOS
was updated by Apple, older versions aged out of support, and brew also stopped
supporting them. Our travis xcode9.2 at the time stopped getting binary
packages (kegs) from brew because of that, and started having to compile
packages which is what was causing the timeouts.
Updating our xcode version allowed us to get binary packages from brew again,
so the workaround of constant output to avoid timing out while compiling large
packages is no longer needed.
Fix running qTox in environments that set 'BUILD_SHARED_LIBS=ON' at
build-time.
Thanks-to: Andreas Sturmlechner <asturm@gentoo.org>
Closes: https://github.com/qTox/qTox/issues/6183
Profile is required to load personal settings, and Profile was creating the
bootstraplist using personal settings. Instead create the bootstraplist in
initCore, after personal settings have been loaded. This avoids using an
uninitialized proxy type on every profile load.
- Seed random in Core Thread. Core Thread didn't seed random, resulting
in always using the same bootstrap nodes, even when you restart qTox
or change profiles.
- Use QDateTime::currentMSecsSinceEpoch() for seeding random. It
provides a bigger range of numbers than QTime::currentTime().msec()
does, and the latter somehow managed to result in approximately the
same first random number being generated, within a certain range.
- Use something a it more sensible than a mod operation to bound random
numbers within a range. It's not perfect either, but a lot better.
Using mod on random skews its distribution too much.
- Use QRandomGenerator's bounded() function to generate random values
within a range.
- Enable QRandomGenerator's usage starting with Qt 5.10.0.
QRandomGenerator is present since Qt 5.10.0, not 5.15.0.
- Bootstrap off every 5th node instead of two consecutive nodes. It's
likely that two consecutive nodes will have the same owner, which
makes some attacks more likely. The node selection algorithm should be
scraped and redone from scratch to be honest though.
