Due to our current allocation strategy. This variable was ending up in a weird state
where jemalloc allocated it using the glibc allocator.
On shutdown this was causing it to try and deallocate through FEX's allocator...Which
is very broken.
This lets linux clean up in this case, at least until the allocator lines are more
strongly written
std::unexpected was deprecated in C++11 and removed from the standard in
C++17. The default unexpected_handler calls std::terminate, so this is
identical behavior.
This class is partially allocated on either side of the allocator fence.
Moves `Sections` over to a unique_ptr so we can clear this variable prior to shutdown.
The rest of the class is allocated prior to switching to FEX allocator
Due to a disjoint mechanism inside of glibc we need to override both the glibc
publicly visible allocation functions AND the hooks.
We had broken the overriding when we changed the default visibility. So first fix that.
Then only override to FEX's allocators once we are ready for it.
Then also replace the hooks.
Additionally have a way to clear the hooks back to default.
No specializations modify this, and even if they did, it would be a
little confusing to statefully modify the string this way.
Instead, we can make it read-only.
The syscall is defined as taking in an array, so we can construct the
std::vector in place and surround it.
This also fixes an edge case where an out of bounds access on the
Host_iovec vectors could occur if these syscalls were called with an
iovcnt of zero (.at would cause an exception to be thrown).
Looking into the syscalls for readv and writev, these just return early
if a size of zero is passed in.
Similarly to #1064, an application could potentially pass in bad values
that could result in assertions/exceptions being thrown, so we can
guard against that.
Despite the manual saying that applications *must* not pass
maxevents less than or equal to zero, against all odds, this is
still a handled case in the kernel, so some application out there
may rely on this behavior.
Similarly to #1064, an application could potentially pass in bad values
that could result in assertions/exceptions being thrown, so we can guard
against that.
Despite the manual saying that applications *must* not pass maxevents
less than or equal to zero, against all odds, this is still a handled
case in the kernel, so some application out there may rely on this behavior.
std::unexpected() was deprecated in C++11 and removed from the standard
in C++17. The default unexpected_handler would call std::terminate
anyway, and given we don't explicitly set a termination handler (as far
as I can tell), this retains identical behavior.
std::function is allowed to allocate if the size of captures exceeds its
internal storage buffer. It's unlikely this is regularly going to be the
case, but we can allow for avoiding it where necessary.
Allows for better detection of out of bounds accesses, as library
implementations generally allow conditional enabling of bounds checks
through preprocessor defines.
When floats and doubles were converting to integers we weren't doing the correct transformation.
AArch64 provides direct ops for all four of the op types. So lets use them
- f32 -> int64
- f32 -> int32
- f64 -> int64
- f64 -> int32
Doesn't fully fix the case of overflow for AArch64 since overflow behaviour is different.
x86 returns 0x8000'0000 or 0x8000'0000'0000'0000 while AArch64 saturates to the maximum signed
integers. Can't work around that without checking overflow flags.
This does solve the typical case though.
Fixes audio problems in all FMod games.
The SSE 4.1 path of these tests seemingly work, it's the setup code before the
test that is broken.
We will need to find out why these are failing later
If the source GPR had data that was larger than the element it would overwrite other elements
Mask it correctly. This then matches behaviour with the other CPU backends
Ryan Houdek