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.
Extend the get_nearest_symbol_at_address() private runtime_loader
export to include imageName and exactMatch arguments.
The imageName holds the SONAME of the image, if available, so cannot
neccessarily be extracted from the image path.
Whether or not there was an exact match, i.e. the symbol with its size
contains the address, is now returned in exactMatch.
luroh was so kind to compile those for gcc4. cdrtools don't build on x86_64,
so there's no reason provide a 64bit BurnItNow version either.
Corrected name of gcc2 source package of burnitnow.
The script runs the guarded heap allocation output through c++filt to
demangle stack trace symbols and filters out a list of known globals
that are never freed. It also allows to exclude further patterns
provided on the command line.
This adds libroot_guarded.so to the HaikuDevel package. It is the same
as libroot_debug with the debug heap swapped out for the guarded heap.
The guarded heap has some useful features that make it desirable to use
while having the disadvantage of a large memory and address space
overhead which make it unusable in some situations. Therefore the
guarded heap cannot simply replace the debug heap but should still be
made available. As the heap init needs to happen even before having
environment variables, the heap to use can not be chosen dynamically.
Exposing them through their own libraries is the next best thing.
When enabled (using heap_debug_dump_allocations_on_exit(true) or
MALLOC_DEBUG=e) this causes a dump of all remaining allocations when
libroot_debug is unloaded. It uses terminate_after to be called as
late as possible.
When combined with alloc stack traces this makes for a nice if a bit
crude leak checker. Note that a lot of allocations usually remain
even at that stage due to statically, lazyly and globally allocated
stuff from the various system libraries where it isn't necessarily
worth the overhead to free them when the program terminates anyway.
