Silently saving only part of the data is not nice and confusing.
The error message just says "Out of range" now however, which is not
really great either. We could improve the error reporting, and, as
mentionned in the ticket, also warn in the UI when the limit is reached
(a marker near the shape/path/fill lists maybe?) so the user knows they
need to simplify their picture.
Part of #13978
Change-Id: I978ff3d377b3652c7f1c5fac4f429ade0398d5f7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2852
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The goal here is to avoid potentially expensive fork()ing.
The time for a fork() is (for a process with no real heap usage
and thus few areas) 300-400us on my system. load_image() takes
3000us (3ms) or so, but this of course includes exec() time.
Overall, for compiling HaikuDepot (with a tweaked jam to use
posix_spawn on Haiku, not just on Linux) there is a slight
decrease in time:
before:
real 1m21.727s
user 1m2.131s
sys 0m43.029s
after:
real 1m19.472s
user 1m1.752s
sys 0m41.740s
Which is probably within the realm of "noise", so more benchmarks
are needed. Likely if we tweak our jam usage to not need as many
shells when running commands, this would be a much more noticeable
change.
Change-Id: I217f2476b1ed9aa18322b3c2bc8986571d89549a
On platforms (such as Haiku) where dash is available or can be installed
but is not the default /bin/sh, this can provide a significant improvement
to compile times vs. /bin/bash or other more complex shells.
At least under Haiku, this is around a ~10% "real" time gain for builds.
This also allows one to specify a JAMSHELL by passing that environ
to ./configure.
When HD first loads in a new install, it will experience
a near-empty set of repositories. This is because only
build-time repo caches are present. This change will
cause HD to pull data from remotes on first load, in the
case that the cache is somehow missing and on a user-
initiated update.
Resolves#14840
Change-Id: I4f0e6c9fdba4141841cc167d7953967edb526033
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2821
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The possible insertion range for B_*_ANY_ADDRESS always encompasses the
entire address space. Even though the initial starting point is now
looked up using a binary search tree, actually finding a free spot was
then still done using a linear search from there.
Store a simple insertion hint, the address directly following the
previous insertion of the same type, and use that as the next starting
point. In the common case this reduces the needed iterations to zero or
near zero.
No hint is used for B_*_BASE_ADDRESS specs as it is assumed that the
given base address already serves as such a hint.
Fixes the area creation performance part of #15995.
Change-Id: Ia8ce76eadc341b71de4cf8c34744c2459473bd06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2842
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It iterates over all areas intersecting a given address range and
removes the need for manually skipping uninteresting initial areas. It
uses VMAddressSpace::FindClosestArea() to efficiently find the starting
area.
This speeds up the two iterations in unmap_address_range and one in
wait_if_address_range_is_wired and resolves a TODO in the latter hinting
at such a solution.
Change-Id: Iba1d39942db4e4b27e17706be194496f9d4279ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2841
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This introduces VMAddressSpace::FindClosestArea() that can be used to
find the closest area to a given address in either direction. This is
now trivial and efficient since both kernel and user address spaces use
a binary search tree.
Using FindClosestArea() getting multiple area infos is sped up
dramatically as it removes the need for a linear search from the first
area to the one given in the cookie on each successive invocation.
Change-Id: I227da87d915f6f3d3ef88bfeb6be5d4c97c3baaa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2840
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is analogous to the AVLTree used for kernel address ranges in
VMKernelAddressSpace. It does not use an additional DoublyLinkedList
however.
Using a binary tree speeds up many operations that previously had to
iterate the area list linearly to find normal and reserved areas,
insertion start points, etc. It especially benefits LookupArea which is
called for every page fault and from area_for() when randomly accessing
different areas as that would make the previously used area hint (i.e.
a one level lookup cache) ineffective.
The overhead of the tree versus the doubly linked list for iteration,
insertion and removal is reasonably small and pales in comparison to
what the linear searches previously took up.
Fixes the lookup performance in #15995.
Change-Id: I48319fe6a2e4327826e90ebca7246c7c419b5218
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2839
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
They return the left and right most nodes of the entire tree, i.e.
starting from the root node.
Change-Id: I651a9db6d12308aef4c2ed71484958428e58c9bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2838
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It combines the intersection check and setting address, size and offset
so that they fall within the area.
Change-Id: Iffd3feca75d4e6389d23b9d70294253b4c3d1f4c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2837
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts parts of hrev52546 that removed the B_KERNEL_AREA
protection flag and replaced it with an address space comparison.
Checking for areas in the kernel address space inside a user address
space does not work, as areas can only ever belong to one address space.
This rendered these checks ineffective and allowed to unmap, delete or
resize kernel managed areas from their respective userland teams.
That protection was meant to be applied to the team user data area which
was introduced to reduce the kernel to userland overhead by directly
sharing some data between the two. It was intended to be set up in such
a manner that this is safe on the kernel side and the B_KERNEL_AREA flag
was introduced specifically for this purpose.
Incidentally the actual application of the B_KERNEL_AREA flag on the
team user data area was apparently forgotten in the original commit.
The absence of that protection allowed applications to induce KDLs by
modifying the user area and generating a signal for example.
This change restores the B_KERNEL_AREA flag and also applies it to the
team user data area.
Change-Id: I993bb1cf7c6ae10085100db7df7cc23fe66f4edd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2836
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The code in the Resize and Rebase methods was identical except for the
iterator.
Change-Id: I9f6b3c2c09af0c26778215bd627fed030c4d46f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2835
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows switching from another recursive_lock, mutex or read-locked
rw_lock analogous to the switching possibilities already in mutex.
With this, recursive_locks can be used in more complex situations where
previously only mutexes would work.
Also add debugger command to dump a recursive_lock.
Change-Id: Ibeeae1b42c543d925dec61a3b257e1f3df7f8934
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2834
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If a system call performed by SSL_read is interrupted by a signal, it
seems to set its error to SSL_ERROR_WANT_READ. This triggers logic
added in hrev53853 which assumes the caller is doing async reads and
returns B_WOULD_BLOCK.
This breaks uses of BSecureSocket that do blocking reads.
* Detect interrupted signal by checking for EINTR in errno.
* Adding this retry loop to BScureSocket::Write as well since it can
have the same problem.
Resolves issue #15853.
Change-Id: I8198a8496fa3a2ccee00bda87375a482a0d4ba3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2825
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
After this patch "UnitTester BDirectory" passes.
Most of this test suite already documented the differences in behavior
between BeOS R5 and Haiku. I verified whether these comments were
accurate and removed the cases which handle BeOS specific behavior.
Most of the differences are just Haiku using more specific errors:
* Initializing BDirectory with an entry that is not a directory
results in B_NOT_A_DIRECTORY.
* There is obviously no /boot/beos. Use /boot/system for this test
instead. BDirectory::IsRootDirectory returns true for this path
since it is the root of the system package.
* Initializing to child path "" results in B_ENTRY_NOT_FOUND instead
of successful initialization with B_OK only to later return
B_BAD_VALUE if the BDirectory is used.
* BDirectory::Find(NULL, BEntry*) doesn't touch the BEntry parameter
since the provided path is NULL, where BeOS R5 will set the BEntry's
status to B_BAD_VALUE.
* Clean up -Wparentheses warnings for assertions of the form
CPPUNIT_ASSERT(path == existingSub == B_OK), which is another way of
saying path != existingSub. This is because the path ends up being a
normalied path, but the input path is not. For example
/tmp/existing-dir becomes /boot/system/cache/tmp/existing-dir. I
verified that this is the same behavior as BeOS, and then added some
normalized paths to compare against.
Change-Id: I5125ef221fba92793959efead96d7daaa181a119
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2826
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It cause starting launch_daemon for every test_app_server run.
Change-Id: I061ee1e1a7bb18f0e471a03885fbf1168393ba5b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2831
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Disable the changelog tab in the case that a package
has no changelog. Also disable the contents tab and
do not attempt to load the package contents in the
case where a package is not installed on the host.
Resolves#15299
Change-Id: Id17daf46aba6709f35438db2ee30f3485fc251ea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2749
Reviewed-by: humdinger <humdingerb@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Addresses part of #15595.
Added all of the missing blocks so that the full Unicode 13 set is
represented.
Change-Id: I3f54cb5dfba14050745287a7a36b22ad3d957b91
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2816
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
The memory map may be unordered and include overlapping ranges. To make
sure that nothing gets included as usable that should actually be
excluded, first scan for all usable ranges and add them, then remove
anything unusable from these ranges again.
To calculate the amount of unusable memory, count the total after the
first pass and then subtract the total after the second. This way, only
unusable ranges that actually overlap physical memory (and therefore
reduce the amount of usable memory) get excluded.
Note that the explicit ignore of the ACPI reclaim memory is subsumed by
the above. We still don't want to add this region to the usable memory
map, as that would allow the kernel to allocate pages into that region,
possibly corrupting ACPI tables before they were used. We also don't
want to add it as an allocated range, as it is not guaranteed that ACPI
is done with the tables before the unused bootloader ranges are freed in
the kernel.
Also add the missing unusable memory amount from ignoring the first MiB
of memory in the EFI loader.
May fix#16056 although it is not certain that graphics memory ranges
are actually included in the memory map.
Change-Id: Ie7991d2c4dcd988edac2995b3a7efc509fa0f4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change capitalization in the titles of alerts. Change
alerts' warnings to avoid the word "Haiku".
Resolves#16117
Change-Id: Id9aacf83d7e8364a1e9b0bfa9a98532108f906e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2808
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the system is currently loading-up and populating
data and the user quits then it was crashing because
of a call to a deleted ProcessCoordinator object.
This change implements the reference as BReference
ensuring that the ProcessCoordinator object is only
deleted after it is not used anywhere.
Resolves#16109
Change-Id: If535c151819da37d502283af3745e4148da69026
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2797
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This fixes a SEGFAULT in the tcp add-on reported in issue #15952. See
that issue for some analysis.
The short version is that, when closing a session over the loopback
interface, there is a special branch which skips the TIME_WAIT state
and instead just releases the socket while handling a RST/ACK
segment. If the timing is right this can lead to the reference
counts becoming imbalanced, leading to the code in tcp_receive_data
segfaulting when it tries to release the reference it acquired from
EndpointManager::FindConnection.
I can't find any other systems which skip the TIME_WAIT state with
loopback sessions, and I'm not entirely certain that it's a totally
safe thing to do anyway. This patch instead just treats local sessions
the same way it does a remote session and uses the TIME_WAIT state.
Any workload which creates and discards lots of ephemeral sockets can
just use SO_REUSEADDR to handle this situation like any other system.
To add a final bit of safety, the only place where a net_socket can be
used after calling gSocketModule->release_socket(net_socket*) is in
tcp_receive_data(). release_socket() returns true if the reference
count falls to zero, deleting the socket. There was an unused segment
action flag DELETE_ENDPOINT that I renamed to DELETED_ENDPOINT, which
is used by tcp_receive_data to know whether its safe to release its
reference to the socket after calling TCPEndpoint::SegmentReceived().
Change-Id: I2652fb225c3c8419234cfd627f74ff2de8402003
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2793
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fixes#15982.
Added font to UnicodeBlockView. Cache Unicode "Blocks" for both
UnicodeBlockView and CharacterView. Added lookup of non-Be Unicode blocks
(i.e. blocks with 'kNoBlock' specified). Gray out non-found blocks.
NOTE: tested fontconfig extensively in another environment and the shown
blocks match what fontconfig returns. However, you may sometimes see
characters in blocks that aren't 'included' in a font. I haven't figured
out why that occurs.
Change-Id: Ia3c7f8ccc6dc43c5ce062ed002846c861a8fa223
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2739
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
In single package mode there was a crash owing to the
status bar not being present. This may as well be
added because it provides some feedback that the
application is actually doing something. The
behaviour of this is not ideal because the feedback
could be better, but it will resolve the crash
issue this ticket is raising.
Resolves#15964
Change-Id: I603a7b163139859f0c46a35ead0809e5d82e0f8d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2791
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This class can potentially be accessed by multiple "tabs" (windows)
at once, so it must be read/write locked to account for that.
Fixes#16027.
Change-Id: I9cc741874caed4997497b03c8893bc2acb0e6fe7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2779
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Each TCPEndpoint has two BufferQueue members, one for the send queue
and one for the receive queue.
If DEBUG_BUFFER_QUEUE is enabled, then most methods of BufferQueue
call BufferQueue::Verify(), sometimes twice. This member function
performs some sanity checking which requires iterating through every
net_buffer in the queue.
Disabling this in a debug build improved throughput by a factor of 5x
over the loopback interface on my laptop. Using iperf the measured
throughput went from 900Mbps to around 4.8Gbps.
This patch turns this sanity checking off for release builds.
* Rename DEBUG_BUFFER_QUEUE to DEBUG_TCP_BUFFER_QUEUE
* Change the default in BufferQueue.h to disabled
* Set DEBUG_TCP_BUFFER_QUEUE to KDEBUG_LEVEL_2 in
kernel_debug_config.h
Change-Id: I262dac5d7e2889d2942bbdcf6b667cc0cbafa4c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2780
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Our sniffing rule is not perfect, but it is already a lot better than
what was done here.
Partially fixes#14437 (the icons also fails parsing for other reasons,
but with an error message, at least)
Change-Id: I25475b419b5fbe863c71f553a336757d7950bf48
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2662
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The parser was based on an old example from agg. NanoSVG is originally
based on the same code, but has lots of bugfixes. So it makes sense
to use it.
Nanosvg revision 25241c5a8f8451d41ab1b02ab2d865b01600d949
Fixes#5955, #8586, #13021.
Change-Id: I38ff9aa4e1d403c41979ebe42f7b45d4500a870c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2661
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This change removes two mistakes I made a long time ago
that caused unnecessarily copying of lists of data. This
fix speeds up the UI alot.
This change also clears data in UI list elements when a
bulk load is requested. It stops clearing otherwise and
instead uses "add" and "remove" operations in the lists
which is OK now because the UI list elements are much
faster than they have been in the past. This removes
the strange clean-and-reload that was visible in the UI
previously.
A threaded package loading system was put in place a long
time ago, but with these performance improvements this
mechanism is no longer necessary; it has been removed to
simplify the code.
Fixes#16012
Change-Id: I393cee929695726539602b51630ae285fb8384f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2748
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The local storage of the various repositories' config
needs to cater for different generations of storage
formats and also needs to be able to swap out legacy
repository identifiers.
Change-Id: Ib4b3857254b7b703858eff6815e2d6c54d69da3c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1963
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
