Since RefPtr<T> decrements the ref counter to 0 and after that starts
destructing the object, there is a window where the ref count is 0
and the weak references have not been revoked.
Also change WeakLink to be able to obtain a strong reference
concurrently and block revoking instead, which should happen a lot
less often.
Fixes a problem observed in #4621
The new algorithm is an iterative one with an arbitrary threshold for splitting
curves. It splits curves evenly. This should theoretically be less accurate
than the existing recursive approach, but seems to give subjectively better
results in practice.
I'm planning to make this a minimal-allocation TTF parser. This will
speed up start-up time for applications, but have some overhead for
rasterizing glyphs. Which should be okay, since rasterized glyph bitmaps
should be cached anyway.
This commit just adds the loading of the HEAD table.
When doing the cast to u64 on the page directory physical address,
the sign bit was being extended. This only beomes an issue when
crossing the 2 GiB boundary. At >= 2 GiB, the physical address
has the sign bit set. For example, 0x80000000.
This set all the reserved bits in the PDPTE, causing a GPF
when loading the PDPT pointer into CR3. The reserved bits are
presumably there to stop you writing out a physical address that
the CPU physically cannot handle, as the size of the reserved bits
is determined by the physical address width of the CPU.
This fixes this by casting to FlatPtr instead. I believe the sign
extension only happens when casting to a bigger type. I'm also using
FlatPtr because it's a pointer we're writing into the PDPTE.
sizeof(FlatPtr) will always be the same size as sizeof(void*).
This also now asserts that the physical address in the PDPTE is
within the max physical address the CPU supports. This is better
than getting a GPF, because CPU::handle_crash tries to do the same
operation that caused the GPF in the first place. That would cause
an infinite loop of GPFs until the stack was exhausted, causing a
triple fault.
As far as I know and tested, I believe we can now use the full 32-bit
physical range without crashing.
Fixes#4584. See that issue for the full debugging story.
This is a new NotesEntry type which will allow applications to embed
arbitrary metadata in crashdumps (stored as a JSON string). It will be
used to store an assertion message, for example.
