This 'data loss' was introduced in 809a8ee693, because
I hoped we could eventually outlaw overlong paths entirely. This sparked some discussion:
https://github.com/SerenityOS/serenity/discussions/4357
Among other things, we agree that yeah, the Kernel can and should be able to return
paths of arbitrary length. This means that the 'arbitrary' maximum of PATH_MAX in
UserspaceEmulator should be considered to be unnecessary data loss, and as such, needs to
be fixed.
The realpath syscall can attempt to return arbitrarily long paths, in particular
paths that are longer than PATH_MAX. The only way to detect this case is
checking whether 'rc', the true length of the returned path including NUL byte,
exceeds our buffer length. In such a case, the buffer contains invalid data.
All Serenity code calls LibC's realpath() with a nullptr buffer, meaning that
realpath is supposed to allocate memory on its own. All Serenity code can handle
arbitrarily long paths returned by LibC's realpath, so it is safe to "do the
dance" and repeat the syscall with a new buffer.
Ports are likely to be graceful in this regard, too. If a Port calls realpath()
with a pre-allocated buffer, however, there is nothing better we can do than
return a truncated buffer.
Now that WindowServer broadcasts the system theme using an anonymous
file, we need clients to pledge "recvfd" so they can receive it.
Some programs keep the "shared_buffer" pledge since it's still used for
a handful of things.
I've reached out to all of these authors asking if they would like to
claim the bounty and no one did. Let's list them on the website anyway
since it's fun to read about them. :^)
The priority boosting mechanism has been broken for a very long time.
Let's remove it from the codebase and we can bring it back the day
someone feels like implementing it in a working way. :^)
These changes are arbitrarily divided into multiple commits to make it
easier to find potentially introduced bugs with git bisect.
This commit touches some dbg() calls which are enclosed in macros. This
should be fine because with the new constexpr stuff, we ensure that the
stuff actually compiles.
The consolidation of the initialization code between HTTP and HTTPS
downloads was capturing the "job" local by reference, which was not safe
after we left the init() scope.
Fix this by getting the HTTP::Job from the Download object instead.
64 was cutting it pretty close, especially now as we start using file
descriptor passing more and more.
This (1024) matches many other systems, and if we need more there's
always sys$poll().
IPC::File should only be used when there's an actual file to pass.
Invalid ShareableBitmaps don't have a backing file, so fix this by
first encoding a "valid" flag.
Whilst SystemMenu maintains a constant WindowServer connection, there
isn't always a Window active on that connection to listen for theme
changes - this causes the current theme in this process to fall out of
sync with the rest of the system. This fixes this problem by
re-requesting an UpdateSystemTheme message when the dialog is
instantiated.
Adds a mechanism through which windowing clients can re-request an
UpdateSystemTheme message. This is currently used in SystemMenu's
ShutdownDialog to refresh it's theme when the dialog is instantiated.
Killing remaining threads already happens in Process::die(), but
coredumps are only written in Process::finalize(). We need to keep a
reference to each of those threads to prevent them from being destructed
between those two functions, otherwise coredumps will only ever contain
information about the last remaining thread.
Fixes the underlying problem of #4778, though the UI will need
refinements to not show every thread's backtrace mashed together.
