We can now route Android analytics through Common::HttpAnalyticsBackend, drop the Volley sender, and keep the JNI layer limited to only transfer metadata since https://bugs.dolphin-emu.org/issues/11772 has been fixed.
Push and wait on WorkQueueThread items using PushBlocking. Previously we
created a Common::Event sync_event on the caller's stack, called Wait on
it, then had the WorkQueueThread call Set on the sync_event once the
thread was done.
In addition to being simpler the new way avoids a use-after-free that
could happen in convoluted and unlikely yet possible thread scheduling
sequences.
One such case can be triggered as follows:
* Set your audio backend to Cubeb
* In CubebStream::SetVolume set a breakpoint at the call to Wait and at
the call to cubeb_stream_set_volume.
* Start a game.
* Continue until the Cubeb Worker thread hits the
cubeb_stream_set_volume breakpoint and Emuthread hits the Wait
breakpoint, freezing each thread when it hits its breakpoint.
* Unfreeze Cubeb Worker.
* In Event::Set set a breakpoint at the end of the scope containing the
lock_guard such that the guard has been constructed but not destructed
when the breakpoint is hit.
* Continue until that breakpoint is hit by Cubeb Worker. If other
threads hit it first keep going.
* Freeze Cubeb Worker.
* For convenience remove the breakpoint in Event::Set so other threads
don't trigger it.
* In CubebStream::SetRunning set a breakpoint at the call to Wait.
* Unfreeze Emuthread and continue until the breakpoint is hit.
* In Cubeb Worker go to Event::Set and examine the values of m_mutex's
member variables. In Visual Studio Debug these are locking_thread_id
== 0xcccccc01 and ownership_levels == 0xcccccccc. This is the result
of Visual Studio overwriting the memory used on the stack by
sync_event in CubebStream::SetVolume with cc bytes to represent
uninitialized memory on the stack (since that function already
returned), and then allocating enough memory on the stack when calling
AudioCommon::SetSoundStreamRunning and then CubebStream::SetRunning
that it overwrote one byte of the memory formerly occupied by
locking_thread_id.
* If you unfreeze Cubeb Worker at this point it will trigger the lock
guard's destructor which will then try to unlock m_mutex. Since
m_mutex is no longer in scope this is a use-after-free, and in VS
debug triggers a debug assert due to locking_thread_id not matching
the current thread id.
Displays a different message at game launch if RetroAchievements fails specifically due to an invalid or expired API token, instructing the player to log back in with the game closed.
When the interpreter calls MSRUpdated, we should update the membase
variable. Not because the interpreter itself needs it, but because the
JIT needs it if it's falling back to the interpreter for an instruction
that sets the MSR.
Additionally, the JIT's FallBackToInterpreter needs to read back the new
membase value afterwards.
This fixes games crashing on JitArm64 if mtmsr is set to fall back to
interpreter. I was unable to reproduce the issue on Jit64, presumably
due to a fortunate series of coincidences (instructions that set MSR are
always followed by an exception exit, and
PowerPCManager::CheckExternalExceptions was always calling
JitInterface::UpdateMembase, and Jit64::WriteExceptionExit was always
calling Jit64::EmitUpdateMembase.)
