The Size column in the "File systems" tab of SystemMonitor
had a rendering artifact where the bounding box outline would
be drawn in the same location as the text. This makes the text
look strange and hard to read.
Pad the size with a signle space character on either side to
give the text a gap on each side.
Each allocation header was tracking its index into the chunk bitmap,
but that index can be computed from the allocation address anyway.
Removing this means that each allocation gets 4 more bytes of memory
and this avoids allocating an extra chunk in many cases. :^)
When committing to a new executable, disown any shared buffers that the
process was previously co-owning.
Otherwise accessing the same shared buffer ID from the new program
would cause the kernel to find a cached (and stale!) reference to the
previous program's VM region corresponding to that shared buffer,
leading to a Region* use-after-free.
Fixes#1270.
When pressing the Left arrow key, we now travel to the parent_index()
of the currently selected index. Our implementation of parent_index()
was always returning an index with column 0, instead of using the
same column as the current index.
This prevented the selected item from looking selected.
This makes unknown addresses accumulate their children together in the
treeview, which turns out to be a bit more useful than having hundreds
of unique garbage addresses each with their own subtree.
Since we're gonna throw away these stacks at the end of exec anyway,
we might as well disable profiling before starting to mess with the
process page tables. One less weird situation to worry about in the
sampling code.
You can now profile a program from start to finish by doing:
$ profile -c "cat /etc/passwd"
The old "enable or disable profiling for a PID" mode is accessible via:
$ profile -p <PID> -e # Enable profiling for PID
$ profile -p <PID> -d # Disable profiling for PID
The generated profile is available via /proc/profile like before.
This is far from perfect, but it at least makes profiling a lot nicer
to use since you don't have to hurry and attach to something when you
want to profile the whole thing anyway.
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
