With this information, it's a bit easier to intuit the current 'process tree'.
If you're reading this, can I convince you to implement a nice process tree for
SystemMonitor? It could be via PPID (unbounded depth), or SID+PGID (depth 3).
Or something else entirely :D
This is to prevent bugs like #3091 (fixed in
9810f8872c21eaf2aefff25347d957cd26f34c2d) in the future; we generally
don't want Interpreter::run() to be called if the interpreter still has
an exception stored. Sure, it could clear those itself but letting users
of the interpreter do it explicitly seems sensible.
We don't want to carry over exceptions across multiple
Document::run_javascript() calls as Interpreter::run() and every of its
exception checks will get confused - in this case there would be an
exception, but not because a certain action failed.
Real-life example:
<script>var a = {}; a.test()</script>
<script>alert("It worked!")</script>
The above HTML will invoke Document::run_javascript() twice, the first
call will result in a TypeError, which is still stored during the second
call. The interpreter will eventually call the following functions (in
order) for the alert() invocation:
- Identifier::execute()
- Interpreter::get_variable()
- Object::get() (on the global object)
That last Object::get() call has an exception check which is triggered
as we still carry around the exception from earlier - and eventually
returns an empty value.
Long story short, the second script will wrongly fail with
"ReferenceError, 'alert' is not defined".
Fixes#3091.
Sometimes people write strange things like "assert(x), something();"
and this will not work if "assert(x)" expands to "".
So make it expand to ((void)0) instead.
ByteBuffer::slice_view() allocates a new ByteBuffer object,
which as a RefPtr and everything.
Nowadays it should probably return a Bytes / Span<u8>, but AES was only
using slice_view() to extract the pointer again. So just add ady a
range check at the top, and do pointer arithmetic to do the same thing
faster.
Reduces time to run `disasm /bin/id` by a bit under 40%,
from ~8.3s to ~5s (min-of-3 runs).
So far, clicking on a link from the Markdown/HTML preview Web::PageView did
nothing - now we pass that link to Desktop::Launcher, which will then
open it in Browser, FileManager, another TextEditor instance etc.
We need to always return from Thread::wait_on, even when a thread
is being killed. This is necessary so that the kernel call stack
can clean up and release references held by it. Then, right before
transitioning back to user mode, we check if the thread is
supposed to die, and at that point change the thread state to
Dying to prevent further scheduling of this thread.
This addresses some possible resource leaks similar to #3073
Setting it in load() excludes users of ELF::Loader that don't actually
call load() but only use the Loader for symbolication purposes.
Perhaps the factoring here is not ideal.
When maximizing a window that is blocked by a modal window, only
maximize the top window in the stack. However, if the stack is
minimized, restore all of them in addition.
Fixes#3074
Fixes the problem reported in #3073. While trying to write a test
for this, I thought I'd use
Shell -c 'for i in $(seq 100) { echo $i }' | head -n 1
but that makes the cpu spin at 100% and doesn't terminate even
with this fix here. But at least piping disasm into head now works.
By having a separate list of constructors for the kernel heap
code, we can properly use constructors without re-running them
after the heap was already initialized. This solves some problems
where values were wiped out because they were overwritten by
running their constructors later in the initialization process.
