* Before this commit address bar used:
B_MENU, B_LIST, B_DOCUMENT colors.
With strange results during customization.
* Now the address uses list user colors.
* Partialy fixes#10840.
The model was owned by the info window and is gone at the point where
the AttributeView is destroyed. Since the extra check whether the model
is a symlink isn't really needed at all, I opted to just remove it
instead of destroying the AttributeView sooner or unsetting its model.
The layout item representing the layout of the view to be removed is
owned by the view and must not be deleted. The layout only owns the
item if a new layout item was created when adding the view, i.e. when
it did not have a layout.
Fixes the underlying issue that triggered #11976.
Removing the view from the window and deleting it is fine. This is a
quick fix for #11976. The underlaying issue of how BLayout::RemoveView
should work still needs to be fixed.
* Do not define the symbols by default, as they are not in the default
libraries.
* Adjust jamfiles of all code using BSD extensions to define
_BSD_SOURCE.
* This makes Haiku slightly more compliant to standard C/POSIX.
Because of the virtual hooks a BLayout must never be destroyed while it
still has layout items. If these items are only removed from the layout
in its destructor, the subclass version of hooks like ItemRemoved() are
not called anymore. This lead to leaks because many BLayout subclasses
use the ItemRemoved() hook to clean up associated data (as is suggested
explicitly in the BLayout documentation).
In the same line of thought, a BLayoutItem must never be deleted when it
is still attached to a layout, as it similarly has virtual hooks like
DetachedFromLayout() that can not be called at this point anymore.
The destructors of BLayout and BLayoutItem now have debugger calls in
case these conditions are not met which should help to avoid
accidentally introducing such hard to debug issues.
To ensure the correct destruction order the sequence is now:
* Destroy the child views first. This cleans up their layout items while
the layout tree is still intact.
* Unset the view layout before removing layout items so it can properly
detach from the layout instead of just deleting it.
It works analoguous to BView::RemoveSelf(), i.e. it removes itself from
the parent (layout in this case) and returns whether or not it had and
was successfully removed from said parent.
... especially for SendMessage and SendReply.
* Delete the item's message if AddItem does not return successfully.
* Fixes#11934.
Signed-off-by: Adrien Destugues <pulkomandy@gmail.com>
The full size of the entry, including the size of the following
addresses, was used when copying the request instead of just the request
buffer size. Also clear the request buffer to 0 as not all of it is
otherwise initialized.
The BNetworkRoute class manages a route_entry and the sockaddr's
associated with it. It replaces the direct use of route_entry in the
BNetworkInterface API.
Using route_entry is fragile and inconvenient as it only holds pointers
to the sockaddr's. When getting a list of routes from the kernel, each
route_entry is set up so that its pointers point into the single flat
buffer that is passed around. Creating a copy of the route_entry and
then deleting the flat buffer makes the pointers in the copy stale.
Returning these route entries therefore always lead to a use-after-free
when they were eventually used.
BNetworkRoute also takes over the code and functionallity of getting
routes from RouteSupport. The corresponding method in BNetworkRoster is
replaced by a static method in BNetworkRoute.
Also distinguish between the default route and gateway of an interface.
GetDefaultRoute() now gets the default BNetworkRoute for the interface
while GetDefaultGateway() gets the associated gateway address within
that default route. Adjust network preferences panel to this change.
Note that we currently only seem to have per interface default routes
and not an actual global default route. This was already the case before
these changes and I did not further investigate what this means.
* The changes for pi2 support led to the virtual addresses overlapping
with the page table again on the beagle, because the kernel address
space overlaps with the physical RAM identity mapped. Try to find a
memory range in a way that will work in both cases.
The stack base and end addresses are stored in TLS slots that are
prepared when enabling stack traces and filled in lazily on use for
each thread. This avoids the need of calling get_thread_info to get
these values.
Also simplifies the code somewhat due to proper frame skipping support.
It can be used to get a stack trace of the current thread. Note that
this works by walking frame pointers and will not produce anything
useful if an application is compiled with the frame pointers omitted.
The stack base and end addresses have to be provided as arguments and
are used to check that the frame pointers fall within that range. These
values are thread specific and can be retrieved with get_thread_info().
No other sanity checks (like checking for loops in the linked list) are
done.
This is a simplified rewrite of the stack trace code from the kernel
debugger.
As this code is common to x86 and x86_64 but is not generic across
architectures I introduced x86_common as a directory to put such
sources.
