The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
Old behavior: Crash due to VERIFY, unless we're completely and entirely out of
memory (m_available_ranges being empty), in which case it would return -ENOMEM.
New behavior: Return ENOMEM (and don't crash). In the case of nullptr,
also emit a helpful diagnostic.
Note that MAP_FIXED with nullptr is technically okay, but tends to be a sign
that something went wrong.
Also, this should improve mmap performance marginally, as it pulls the check out
of a loop that does not modify any parts of the check.
UE is now self-hosting! Fixes#5709.
However, this still needs some love: "ue UserspaceEmulator true" spits out tons
of error messages, probably false-positives, and takes about 229 seconds to run.
Then again, true-in-ue-in-ue-in-Qemu is three levels of emulation, so no wonder
it takes a long time! :D
Since there is usually no correlation between guest memory-layout and UE memory-layout,
this option does not make any sense. Especially since we provide nullptr.
The auditing code always starts by checking if we're in one of the
ignored code ranges (malloc, free, realloc, syscall, etc.)
To reduce the number of checks needed, we can cache the bounds of
the LibC text segment. This allows us to fast-reject addresses that
cannot possibly be a LibC function.
Accesses in the header (or trailing padding) of a malloc block should
not be associated with any mallocation since only the chunk-sized slots
actually get returned by malloc.
Basically, allow address-to-chunk lookup to fail, and handle such
failures gracefully at call sites.
Fixes#5706.
We don't want to audit accesses into the region *while* we're setting
up malloc tracking for it. Fetching the chunk size from the header
was tripping up the auditing code.
This returns ENOSYS if you are running in the real kernel, and some
other result if you are running in UserspaceEmulator.
There are other ways we could check if we're inside an emulator, but
it seemed easier to just ask. :^)
We now restart the language server transparently if it crashes.
If the language server crashes too frequently (current threshold is
twice within 3 seconds), we give up and will not attempt to restart it
again. HackStudio will still work fine, but features that depend on the
language server will not function.
To support this change we use a new class, 'ServerConnectionWrapper',
that holds the actual ServerConnection and is responsible for restarting
the language-server if it crashes.
Closes#5574.
