Beforehand we were dividing the frame width by the profile length in ms
and then dividing the frame width by the result once more, which is
equivalent to (but slower) just using the length in ms directly, aside
from the case in which the profile is less than 1 ms long, in which
case this would trigger undefined behaviour due to the division by zero
This function implements CSS color syntax, which is case-insensitive in
HTML contexts. Making it insensitive here means not having to remember
to do it in every user, (many of the HTML elements do not do this,) and
means they don't have to produce a lowercase copy of the input string
before passing it.
If a mouse button was clicked, `EventLoop::drain_mouse()` would always
send the last MousePacket state to the screen input - even if that
state is equivalent to the last state sent as part of the button logic.
By remembering if the state was already sent, we prevent sending that
state a second time saving some resources in the process.
Bit 3 is set here:
c5b2f55981/hw/input/ps2.c (L736)
Spurious mouse packets can be received without this bit set, for
example when double-clicking and keeping the mouse button depressed
instead of releasing it the second time (i.e. mousedown > mouseup >
mousedown). We should not process such packets.
This makes interaction with our buttons much smoother!
Fixes#5881.
Instead of detecting which flag was set in the status register, we can
use the instrument type passed to us. This works because the mouse and
keyboard use different IRQs.
This issue was also present in the kernel, the description of which is
provided in an identically titled commit.
Note that this couldn't have affected any programs running in
UserspaceEmulator as we don't support SSE instructions, and don't seem
to raise faults under any conditions.
The System V ABI requires that the stack is 16-byte aligned on function
call. Confusingly, however, they mean that the stack must be aligned
this way **before** the `CALL` instruction is executed. That instruction
pushes the return value onto the stack, so the callee will actually see
the stack pointer as a value `sizeof(FlatPtr)` smaller.
The signal trampoline was written with this in mind, but `setup_stack`
aligned the entire stack, *including the return address* to a 16-byte
boundary. Because of this, the trampoline subtracted too much from the
stack pointer, thus misaligning it.
This was not a problem on i686 because we didn't execute any
instructions from signal handlers that would require memory operands to
be aligned to more than 4 bytes. This is not the case, however, on
x86_64, where SSE instructions are enabled by default and they require
16-byte aligned operands. Running such instructions raised a GP fault,
immediately killing the offending program with a SIGSEGV signal.
This issue caused TestKernelAlarm to fail in LibC when ran locally, and
at one point, the zsh port was affected too.
Fixes#9291
If the Value is a non-negative Int32, create a numeric PropertyKey
instead of making a string key.
This makes "ai-astar" test from the Kraken benchmark run in 30 seconds,
down from 42 seconds. :^)
Instead of returning JS::StringOrSymbol, which is a space-optimized type
used in Shape property tables, this now returns JS::PropertyKey which is
*not* space-optimized, but has other niceties like optimized storage of
numeric ("indexed") properties.
This is a specialized string table for storing identifiers only.
Identifiers are always FlyStrings, which makes many common operations
faster by allowing O(1) comparison.
They were previously taking up 9% of samples in a profile of PixelPaint
while selecting a mask, and as a result of moving them to the header
they were inlined, which effectively eliminated them from the profile.
Commit cf0dbc906 recently added the ability for setuid binaries to be
located in /usr/Tests. This should really now be read only to mitigate
the potential misuse of any of the setuid binaries.
By replacing this VERIFY with a thrown Error we no longer crash when
calling a generator function in the AST interpreter. This allows us to
more gracefully handle situation which have not been implemented yet.
In particular this helps the libjs-test262-runner since it can now
continue on to the next tests instead of having the entire process end.
We always use UTF-8, meaning that a single `wchar_t` might be converted
into up to 4 `char`s. This would cause a buffer overflow if something
actually relied on this being the right value.
The C standard states that these symbols should be declared as macros,
not as emum variants as we were doing previously. This is used in some
ports (e.g. bash) to conditionally compile locale-dependent
functionality.
We now use the same trick here as with the errno constants. We keep the
enum, but also create macros that defer to the enum variants.
The main event loop pushes itself onto the event loop stack, and so it
should also pop itself when destroyed.
This will surface attempts to use the event loop stack after the main
event loop has been destroyed.
This lets us avoid using Core::deferred_invoke() which is not usable
during application teardown (as there is no event loop to push the
deferred invocation onto.)
(Not that there is an event loop to fire the processing timer during
teardown *either*, but at least we can exit gracefully with pending
timers, unlike deferred invocations, which hang the process. This is an
area where more improvements are definitely needed!)
This patch moves the templated message parsing code to a virtual
try_parse_messages() helper. By doing that, we can move the rest of the
socket draining code up to ConnectionBase and keep it out of line.
This patch splits IPC::Connection into Connection and ConnectionBase.
ConnectionBase moves into Connection.cpp so we don't have to inline it
for every single templated subclass.
When parse_expression looks at '$((', there are two ways it can end up
in parse_expression again, three consumed characters later. All these
ways fail, so what happened was that the parser tried all possible
combinations, hence taking potentially an exponential amount of time.
1. parse_evaluate swallows the '$(', a new invocation of
parse_expression swallows the other '(', and through
parse_list_expression we're at another parse_expression.
2. parse_evaluate swallows the '$(', but returns a SyntaxError.
parse_expression used to not recognize the error, and treated it as a
regular AST node, calling into read_concat, then a new invocation of
parse_expression swallows the other '(', and through
parse_list_expression we're at another parse_expression.
Fixes#10561.
Found by OSS Fuzz, long-standing issue
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28113
These are marked with ! in the spec. This also adds assertions above
a couple of these operations to be extra sure (the spec also indicates
we should make these assertions).
In the long-term, we should probably have a way to signal decoding
failure. For now, it should suffice to at least not crash. This is
particularly relevant because apparently this can be triggered while
parsing a PEM certificate, which happens during every TLS connection.
Found by OSS Fuzz
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38979
In particular, we implicitly required that the caller initializes the
returned instances themselves (solved by making
UniformBumpAllocator::allocate call the constructor), and BumpAllocator
itself cannot handle classes that are not trivially deconstructible
(solved by deleting the method).
Co-authored-by: Ali Mohammad Pur <ali.mpfard@gmail.com>
This fixes two bugs:
1. `end_offset` was missing the alignment that might have been
introduced while computing `base_ptr`.
2. Ignoring point 1, `end_offset` computed the offset of the first byte
that is outside the current chunk. However, this might be in the
middle of a (hypothetical) object! The loop treats `end_offset` as if
it points to the first byte beyond the last (valid) object. So if the
last few bytes of the chunk are unused, the loop iterates once too
often.
Found by OSS Fuzz, long-standing issue (since 2021-07-31)
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38733
(This probably also resolves some other issues that go through
RegexMatcher.)
See also: 0f1425c895
