When running with -DASAN on and a mod to send 10k messages in quick
succession I was seeing memory corruption within toxext. This was caused
by a race between toxext_iterate and toxext_send being called from
different threads.
Protect the use of functions coming from different threads with a mutex
We are staying on 5.12 instead of 5.15 because 5.12 is supported for
longer. There should be one more release in H2 2021.
Ideally we would switch to 6.2, but qTox doesn't seem to be Qt6-ready
yet.
bsdtar has moved to libarchive-tools package.
Something has changed in the newer gcc or mingw that makes Opus and
Sodium fail to build with:
undefined reference to `__memcpy_chk'
The solution is to use -lssp or -fstack-protector, but while -lssp
worked for Opus, it was breaking Sodium's `make install` as it prevented
the .def file from being generated during the build time for some
reason:
/usr/bin/install: cannot stat './libsodium-24.def': No such file or directory
while -fstack-protector worked just fine, so -fstack-protector was used
for both. This adds a new library dependency on libssp-0.dll.
bodwok (4):
refactor(ui): separation of responsibility for sorting the contact list
fix(build): include QVector type
refactor(ui): code improvement
refactor(ui): code improvement
Partially fix#6345, only PR portion, not nightly or releases.
Unlike travis, we're not caching our brew packages. `actions/cache` doesn't
update the cache on cache hit, making it hard to use a rolling cache like
before. We also don't know what cache key we should use before running, since
it relies on the live package list of brew.
Using a docker image containing brew packages seems like a better option if we
need the speedup going forward. ATM a full build with deps only takes about 12
minutes. Windows builds don't have this issue, since deps there are keyed off of
known versions in our repo.
Current Windows matrix form works, but causes a double-build on dep change due
to both debug/release rebuilding the release deps. Instead, should probably
separate the dep jobs, block build on the dep jobs, and update the cache on dep
jobs, guaranteeing a cache hit on build jobs?
Windows stage 1 and stage 2 can probably be recombined, if they were split due
to travis single build length limits, since GH actions allows much longer single
builds.
* Resolves#6221
* System message schema designed to take enum of message base + args
* New table layout required many updates to the queries executed by
history
* Bonus reduction of history signals/slots by issuing some file transfer
insertions directly when possible
