Source Activity

Syndicate content
Haiku's main repository
Updated: 41 min 47 sec ago

BView: Fix destruction order of layout items.

Tue, 2015-04-14 21:54
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. 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.
Categories: Development

Debugger: Restrict registers via CPU feature detection.

Tue, 2015-04-14 21:44
DebuggerInterface,Architecture{X86,X8664}: - Add hook function for retrieving a feature flag mask for the target CPU, and corresponding implementation in Architecture-specific classes. ArchitectureX86: - Read CPU features on init, and use them to restrict the exposed set of registers such that the MMX and SSE registers will only be visible if the target CPU actually supports the respective instructions. DebuggerInterface,Architecture{X86,X8664}: - Add hook function for retrieving a feature flag mask for the target CPU, and corresponding implementation in Architecture-specific classes. ArchitectureX86: - Read CPU features on init, and use them to restrict the exposed set of registers such that the MMX and SSE registers will only be visible if the target CPU actually supports the respective instructions.
Categories: Development

BLayoutItem: Add RemoveSelf() convenience method.

Tue, 2015-04-14 21:28
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. 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.
Categories: Development

BView: Remove old TODO comment.

Tue, 2015-04-14 20:45
The BShelf is not owned by the BView (nor the BWindow for that matter) and so must not be deleted on destruction. The BShelf is not owned by the BView (nor the BWindow for that matter) and so must not be deleted on destruction.
Categories: Development

BGridLayout: Fix leak of grid.

Tue, 2015-04-14 20:36
Categories: Development

Whitespace cleanup only.

Tue, 2015-04-14 20:36
Categories: Development

53c8xx: build fixes.

Tue, 2015-04-14 20:17
Categories: Development

Set the corret ID when unregistering the buffer.

Tue, 2015-04-14 05:19
Follow-up fix to hrev49035. Follow-up fix to hrev49035.
Categories: Development

ShowImage: Remember save location

Mon, 2015-04-13 20:00
* Fixes #6766. * Fixes #6766.
Categories: Development

cubieboard4: Update SPL bin url to official source

Mon, 2015-04-13 14:15
* Our pull request was accepted * Our pull request was accepted
Categories: Development

Whitespace and style cleanup only.

Sun, 2015-04-12 16:27
Categories: Development

network stack: Copy right amount of data from request buffer.

Sun, 2015-04-12 16:23
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 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.
Categories: Development

arm/mmu: Fix boot on beagle-xm

Sun, 2015-04-12 15:52
* 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 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.
Categories: Development

libbnetapi: Add BNetworkRoute to replace use of route_entry.

Sun, 2015-04-12 15:43
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