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.
As of 2019-10-09, toxme.io was taken offline permanently. Remove UI and code
in qTox relating to it. Revert this commit if it comes back online in the
future.
Fix#5897
When re-evaluating our dependencies we decided that the update bridge
has a high potential for security issues because it's not widely used.
Additionally similar functionality is already present in qTox.
When re-evaluating our dependencies we decided that the update bridge
has a high potential for security issues because it's not widely used.
Additionally similar functionality is already present in qTox.
* When the DB schema was too new we were accessing history anyways. This
has potential to just completely corrupt the DB
* When history was disabled there was a chance we would attempt to write
to history anyways. Added more checks in this area
* Chatform was accessing invalid iterators when there were no displayed
messages. Added a guard for this case
Group calls are supposed to show the name of each member under their
avatars. The color of the text was previously fixed to white regardless
of the background ignoring the color of the background.
This fix ensures that the background color is not the same color as the
label text
Avatars for group members currently in a call are resized depending on
the area they are displayed in. Previously a scrollbar would appear and
disapear based on the size of the contents. This resulted in
oscillations that ended in a SIGSEGV.
This fix avoids the oscillations by fixing the scrollbar to always be
shown
Group calls are supposed to show the name of each member under their
avatars. The color of the text was previously fixed to white regardless
of the background ignoring the color of the background.
This fix ensures that the background color is not the same color as the
label text
Avatars for group members currently in a call are resized depending on
the area they are displayed in. Previously a scrollbar would appear and
disapear based on the size of the contents. This resulted in
oscillations that ended in a SIGSEGV.
This fix avoids the oscillations by fixing the scrollbar to always be
shown
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 previous implementation of hiding the date line would cause 100% cpu
usage. When the date line was shown it would hide the top line, causing
the date line to be hidden again due to a state change in which dates
was visible.
This is a minimal patch to work around the issue by pretending the line
covered by the date line is the first visible line when the dateline is
shown
Fixes#5620
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
Before a bug in qTox would make it possible for a user to try to send an empty
action type message. This would fail to send at toxcore, but still be persisted
in history, causing it to fail every time FauxOfflineEngine tried to resend
it. Moving these stuck messages into the broke_messages table will stop qTox
from attempting to deliver them on each connect, and display in the GUI to
users that the messages aren't really pending anymore.
