[Haiku-commits] r31115 - in haiku/trunk: headers/private/kernel headers/private/system src/kits/app src/system/kernel/vm src/system/libroot/posix/malloc src/system/runtime_loader

[Stephan Assmus]

On 2009-06-19 at 13:09:23 [+0200], axeld at BerliOS <axeld at mail.berlios.de> 
wrote:
> Author: axeld
> Date: 2009-06-19 13:09:21 +0200 (Fri, 19 Jun 2009) New Revision: 31115
> ViewCVS: http://svn.berlios.de/viewcvs/haiku?rev=31115&view=rev
> 
> Modified:
>    haiku/trunk/headers/private/kernel/vm.h
>    haiku/trunk/headers/private/system/syscalls.h
>    haiku/trunk/src/kits/app/ServerMemoryAllocator.cpp 
>    haiku/trunk/src/system/kernel/vm/vm.cpp
>    haiku/trunk/src/system/libroot/posix/malloc/arch-specific.cpp 
>    haiku/trunk/src/system/runtime_loader/images.cpp
> Log:
> * Renamed _kern_reserve_heap_address_range() to 
> _kern_reserve_address_range(),
>   and added a _kern_unreserve_address_range() as well.
> * The runtime loader now reserves the space needed for all its areas first
>   to make sure there is enough space left for all areas of a single image.
> * This also fixes the final part of bug #4008.

It doesn't seem to be the only thing this fixes, although it may still be 
one and the same bug. From my testing with Clockwerk, I could also 
reproduce a situation where decoder plug-ins for clips needed to be opened 
on program start up, since the playlist would open such that a clip would 
immediately need to be rendered on the canvas. These clips would often 
display black while a second instace of the clip later in the timeline 
would display correctly. From when I had all sorts of debugging output in 
libmedia.so, I could see that actual plug-in loading was were it failed for 
the first instance. This is no longer the case and clips seem to display 
reliably. It could also be that they failed to load because of the 
corruption.

Great job, Axel, thanks a lot!

Best regards,
-Stephan