c-toxcore calls the groupCallCallback from it's main thread instead of
the ToxAV thread as expected, this was triggering an assertion.
Aditionally the destructors of Core and CoreAV were fixed, because they
now either crashed or deadlocked qTox when it was closed while a group
call was still running.
This actually fixes two problems:
1) CoreAV and Audio thread both locked the callsLock and audioLock in
different orders, resulting in a deadlock of both threads. This fixed by
using a ReadWriteLock in the CoreAV thread.
2) Multiple functions were emitting signals while holding a lock. This
is unsafe, because the connected slot may acquire any other lock. This
is fixed by releasing the locks before emitting signals.
It doesn't really make sense to assert that the callbacks are coming
from any other thread than CoreAV, when we actually want to ensure the
callback is coming from Core thread.
Remove over agressive assert from sendGroupCallAudio(...), this function
should be callable from any thread.
We we're calling toxav_* functions without synchronizing to any of the
Tox threads.
Additionally remove the call timeout, it creates timers from different
threads, which causes errors.
The call to Core::getGroupPeerNames is expected to return a list where
the index in the list is the group member id. In any error case we were
previously breaking this constraint. It turns out that every time
someone joins a group we call this function before they have a valid
name resulting in their id not being added to the list.
This fix ensures that the list coming out of Core::getGroupPeerNames
always has a full list.
Fixes#5838
On application close we used to access invalid memory associated with
the audio subsystem. This was because on destruction of static variables
we tried to access state associated with an already destructed item.
These variables seem to have no good reason to be static. They should be
tied to a single CoreAV instance and are only accessed through an
existing CoreAV instance.
The call to Core::getGroupPeerNames is expected to return a list where
the index in the list is the group member id. In any error case we were
previously breaking this constraint. It turns out that every time
someone joins a group we call this function before they have a valid
name resulting in their id not being added to the list.
This fix ensures that the list coming out of Core::getGroupPeerNames
always has a full list.
Fixes#5838
Errors are parsed and printed, but which specific node is being connected to
isn't very relevant to any errors that would occur, and the nodes list is
already updated to prune offline nodes based on nodes.tox.chat periodically.
This provides some extra privacy about which connections are being made,
even though the bootstrap nodes are already public.
Use a macro to embed line number of call sight, instead of just using line
number of log site, since logger functions can be called from different
toxcore API usages.
The button didn't work that well and caused all kinds of issues inside
the code, so I replaced it by a notice that changes to the Advanced
settings only apply after a restart of qTox.
In the process I also removed all code that was exclusively used for
that feature.
We may add it back later when qTox's internal architecture makes it less
cumbersome.
* From the archeology I managed, MAX_GROUP_MESSAGE_LEN was a workaround
for an old toxcore bug. Testing removal of this parameter and replacing it
with tox_max_message_length() seems to work fine.
This commit ignores the possibility of invalid length error being thrown
by a title after we've already checked its size the first time. We also
assume that a group chat cannot cease existing while we iterate over the
retrieved groups.
