ProfileViewer will now attempt to open /boot/kernel and use that to
symbolicate kernel addresses (anything above the 3GB mark.)
In other words, if you run ProfileViewer as root, on a profile that
was generated by root, you can now see kernel functions properly
as well. This is not available to non-privileged users.
This commit adds two new behaviour to the key event handler of
the TreeView widget:
Pressing left now jumps to the parent node if the current treenode
is closed or has no children.
Pressing right now jumps to the first children node if the current
treenode is open.
Linux creates holes in block lists for all-zero content. This is very
reasonable and we can now handle that situation as well.
Note that we're not smart enough to generate these holes ourselves yet,
but now we can at least read from such files.
The kernel sampling profiler will walk thread stacks during the timer
tick handler. Since it's not safe to trigger page faults during IRQ's,
we now avoid this by checking the page tables manually before accessing
each stack location.
We're not equipped to deal with page faults during an IRQ handler,
so add an assertion so we can immediately tell what's wrong.
This is why profiling sometimes hangs the system -- walking the stack
of the profiled thread causes a page fault and things fall apart.
If we get an -ENOENT when resolving the target because of some part, that is not
the very last part, missing, we should just return the error instead of panicking
later :^)
To test:
$ mkdir /tmp/foo/
$ mv /tmp/foo/ /tmp/bar/
Related to https://github.com/SerenityOS/serenity/issues/1253
This is apparently a special case unlike any other, so let's handle it
directly in VFS::mkdir() instead of adding an alternative code path into
VFS::resolve_path().
Fixes https://github.com/SerenityOS/serenity/issues/1253
The open menu stack is an internal data structure that outside classes
shouldn't really need to know about. Add MenuManager::has_open_menu()
so that the WindowManager can still know whether a menu is open or not.
We were failing to check if the current menu being set was already open.
This could result in multiple occurrences of the menu in the open menu stack.
When we close all menus descending from a menu we only delete the first
occurrence of a given menu from the menu stack (a fair assumption to make as
a menu should only be open once).
Because of this a menu (or multiple instances of it) could remain in the open
menu stack when it should actually be closed, leading to goofy behaviour.
Fixes#1238
There are various issues with this port that need to be fixed, but it's
at least possible to inspect and modify the SerenityOS repo if I clone
it into the disk image from the outside.
Very cool! :^)
This patch adds a crappy pread() just to get "git" working locally.
A proper version would be implemented in the kernel so that we don't
have to mess with the file descriptor's offset at all.
We were not repainting windows that were occluded at the time of the
theme changing. This patch adds a way to bypass occlusion testing when
invalidating window rects.
Fixes#1249.
