#
2641b03c |
|
13-Jan-2021 |
X512 <danger_mail@list.ru> |
app_server: fix integer overflow in ServerBitmap Integer overflow caused bitmap buffer creation of wrong size and out of bounds access when large bitmap was created. Now allocation failure is reported for large bitmaps. This prevents app_server from crashing while playing YouTube in WebPositive. Fixes #16489. Change-Id: I297aa6e3b79b32a486d297f1239a1fd4397a8a36 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4209 Reviewed-by: Sergei Reznikov <diver@gelios.net> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
|
#
d99d8dbd |
|
27-Aug-2020 |
X512 <danger_mail@list.ru> |
app_server memory management: use ObjectDeleter to mark ownership Make object ownership explicit by use of ObjectDeleter where possible. Change-Id: I499a00aa3390d1510ae284419e73faffa5166430 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2695 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
|
#
577f5876 |
|
21-Jan-2012 |
czeidler <haiku@clemens-zeidler.de> |
Make it possible to reconnect BBitmap to the app_server. * maintain a list of all BBitmaps * refactor the client memory allocator class, its possible now to just clone existing client area
|
#
87e7b978 |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed race conditions in the server's bitmap/picture handling: the objects are now removed from the maps as soon as the client deletes them. This also makes the "client reference" mechanism superfluous I introduced earlier. * ServerApp::SetCurrentCursor() must always call Desktop::SetCursor(), since it is also called whenever the current application changes. This fixes the cursor almost never changing. * Renamed ServerPicture::Usurp()/StepDown() to PushPicture(), and PopPicture(). * Also, they now acquire a reference to the picture in question (ie. the picture you get from PopPicture() also owns a reference you need to free). * ServerApp::CreatePicture() may fail, too. This case is now handled in the code that calls it. * Previously, the ServerWindow tried to process up to 70 messages in one go. That obviously caused bug #4709. Now, we have the additional requirement to not hold the desktop lock for longer than 25 ms. I haven't tested it with Kaleidoscope yet, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35472 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
afad65b2 |
|
19-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Bitmaps and pictures now maintain their client reference independently; clients can no longer release more references than they own. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34130 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
56e44969 |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Use BReferenceable instead of Referenceable. Didn't notice there was a BReferenceable in the first place, thanks Ingo! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33880 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4b0459b2 |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of roling its own solution. * Also removed BitmapManager::DeleteBitmap() - you only call ServerBitmap::RemoveReference(), and that one will notify the manager if needed. * Some more cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33878 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
85a7877f |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* ServerApp's bitmap and picture handling was completely broken, as it ignored concurrency as well as reference counting, causing occasional crashes and memory corruption. * ServerPicture now subclasses Referenceable, and will notify its owner when it's going to be deleted. This might bring some regressions, although I couldn't spot anything wrong yet. * ServerBitmap will now also notify its owner when it's going to be deleted as well. * Switched from the former picture/bitmap lists to a std::map. This also solves the issue of not checking whether or not the bitmap/picture actually belongs to the ServerApp (before, all apps could access and delete all pictures/bitmaps) * Introduced a new fMapLocker that guards the new maps. * ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference after use. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33876 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
63c07622 |
|
26-Jul-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Some style cleanups, no functional change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31759 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ab53bb20 |
|
26-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Export get_bytes_per_row() from InterfacePrivate.h, and use it in ServerBitmap in place of the own rolled implementation. Comment typo fix. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31757 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
de6a19ee |
|
21-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Got rid of fBitsPerPixel (and BitsPerPixel()) in ServerBitmap, since they were nowhere used. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31677 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dcd70f0e |
|
26-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR. * When drawing BBitmaps with scaling in the app_server, use a bilinear filter when a bitmap has this flag set. (Hope nobody objects, otherwise I can revert or improve this. Performance can certainly be improved, since the AGG implementation is too generic. But that goes for the nearest neighbor implementation as well.) * Flags are uint32, fix app_server side code to declare them correctly. Use appropriate link methods in BBitmap and ServerApp. * Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32 in B_OP_ALPHA mode). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26649 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7e1df75 |
|
16-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* get rid of RGBColor usage where it is not needed, this simplified many things, possibly making them a little faster too * mess with decorator button size calculation to make the whole layout scale more agreeable with the font size (no more fixed offsets/insets), but it is work in progress * DefaultDecorator no longer allocated the border color array, it is part of the object now * small memory footprint optimizations in ViewLayer, Decorator and WindowLayer git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22003 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
117b384e |
|
27-Jun-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Implemented the overlay suspend/resume protocol on mode changes; not really tested yet. Also, BBitmap::LockBits() should probably fail when the Bits() are NULL. * The downside is that many more classes now know of each other. * Cleaned up the work divided between the BitmapManager and the Overlay class. * Fixed a memory leak in AS_CREATE_BITMAP in case the bitmap could not be added to the ServerApp's bitmap list. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21512 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fe19cff6 |
|
04-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
No longer invalidates the view when an overlay bitmap is updated. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17319 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0ac013e6 |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Some refactoring: renamed OverlayCookie to Overlay and put it in its own source file. * An overlay is now also hidden in case its is removed from the window. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7c7883b |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* We now have working video overlay - even though the overlay_token handling is currently broken, mode switches probably fail or result in sudden death (didn't try) it's good enough for Radeon cards and VLC (might work with others as well). * Implemented follow modes for view bitmaps (wasn't taken into account at all before). * Switched to a darker overlay color for now (dunno what exactly makes a good candidate there, but this one is good enough for now). * Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
21c8c925 |
|
22-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* With Rudolf's information about relocating overlays, I changed the way memory is managed for those bitmaps: - the shared client memory mechanism is used to allocate a small overlay_client_data structure that contains the actual buffer and a semaphore that you have acquire in order to access it. - LockBits()/UnlockBits() now have a function: you need to call them before accessing the overlay buffer, and you need to keep that lock until you're done with it. * The overlay cookie is now an extra member of the ServerBitmap class. * Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated with the bitmap. * ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay color instead of any contents (this is currently in ugly pink, but will become some dark color later on). * All what's missing from actually being able to use overlays now is to configure them so that they are shown on screen. VLC will now show an empty pink window when overlay video is enabled. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17201 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
68bf2de5 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Refined overlay support a bit: we now allow as many overlay bitmaps to be created as the graphics driver does. * Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected. * We're no longer using the B_OVERLAY_COUNT hook anymore - that one really looks like a misconception to me; I don't see how it can be useful. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17196 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
37b502f2 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented some more overlay support - the overlay bitmap is now allocated via the graphics driver (but not yet shown on screen). I probably got the meaning of the "overlay count" wrong - I guess that you can allocate any number of overlay bitmaps, but can only see "overlay count" on screen at a time (right now, I only allow to create "overlay count" bitmaps). Stephan? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17193 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
16ed1e1d |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed headers/private/servers/app - everything is in src/servers/app now. * Removed DisplaySupport.h, wasn't needed anymore. * Removed private color set functions from InterfaceDefs.cpp - we might want something similar, but definitely not like that. * Minor cleanup, added some missing licenses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16831 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
577f58763be348b31493bc7266dd9f62c4e40f02 |
|
21-Jan-2012 |
czeidler <haiku@clemens-zeidler.de> |
Make it possible to reconnect BBitmap to the app_server. * maintain a list of all BBitmaps * refactor the client memory allocator class, its possible now to just clone existing client area
|
#
87e7b978aacfb3de11892ccd71894acf675ab0b8 |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed race conditions in the server's bitmap/picture handling: the objects are now removed from the maps as soon as the client deletes them. This also makes the "client reference" mechanism superfluous I introduced earlier. * ServerApp::SetCurrentCursor() must always call Desktop::SetCursor(), since it is also called whenever the current application changes. This fixes the cursor almost never changing. * Renamed ServerPicture::Usurp()/StepDown() to PushPicture(), and PopPicture(). * Also, they now acquire a reference to the picture in question (ie. the picture you get from PopPicture() also owns a reference you need to free). * ServerApp::CreatePicture() may fail, too. This case is now handled in the code that calls it. * Previously, the ServerWindow tried to process up to 70 messages in one go. That obviously caused bug #4709. Now, we have the additional requirement to not hold the desktop lock for longer than 25 ms. I haven't tested it with Kaleidoscope yet, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35472 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
afad65b245eb0c70300cbef4929db0ff8ccbec00 |
|
19-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Bitmaps and pictures now maintain their client reference independently; clients can no longer release more references than they own. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34130 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
56e44969478e37ec5a7bae1bd1b09ca6455e70a6 |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Use BReferenceable instead of Referenceable. Didn't notice there was a BReferenceable in the first place, thanks Ingo! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33880 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4b0459b2eef38f07b8c0c4426860dccb61a1134a |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of roling its own solution. * Also removed BitmapManager::DeleteBitmap() - you only call ServerBitmap::RemoveReference(), and that one will notify the manager if needed. * Some more cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33878 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
85a7877f80790d60e084ba8d7e6f1ae5f9a6fee1 |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* ServerApp's bitmap and picture handling was completely broken, as it ignored concurrency as well as reference counting, causing occasional crashes and memory corruption. * ServerPicture now subclasses Referenceable, and will notify its owner when it's going to be deleted. This might bring some regressions, although I couldn't spot anything wrong yet. * ServerBitmap will now also notify its owner when it's going to be deleted as well. * Switched from the former picture/bitmap lists to a std::map. This also solves the issue of not checking whether or not the bitmap/picture actually belongs to the ServerApp (before, all apps could access and delete all pictures/bitmaps) * Introduced a new fMapLocker that guards the new maps. * ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference after use. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33876 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
63c07622f6bab3690e8c413fb11d62ca2c746670 |
|
26-Jul-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Some style cleanups, no functional change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31759 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ab53bb20860dbd591ac92f20ea9288941610302a |
|
26-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Export get_bytes_per_row() from InterfacePrivate.h, and use it in ServerBitmap in place of the own rolled implementation. Comment typo fix. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31757 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
de6a19ee14b11c191b043a7274f6380022155f19 |
|
21-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Got rid of fBitsPerPixel (and BitsPerPixel()) in ServerBitmap, since they were nowhere used. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31677 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dcd70f0e3967582a60a8012431246a3632bf65de |
|
26-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR. * When drawing BBitmaps with scaling in the app_server, use a bilinear filter when a bitmap has this flag set. (Hope nobody objects, otherwise I can revert or improve this. Performance can certainly be improved, since the AGG implementation is too generic. But that goes for the nearest neighbor implementation as well.) * Flags are uint32, fix app_server side code to declare them correctly. Use appropriate link methods in BBitmap and ServerApp. * Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32 in B_OP_ALPHA mode). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26649 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7e1df75609966bdfdb4ed39edf26dd145d8221f |
|
16-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* get rid of RGBColor usage where it is not needed, this simplified many things, possibly making them a little faster too * mess with decorator button size calculation to make the whole layout scale more agreeable with the font size (no more fixed offsets/insets), but it is work in progress * DefaultDecorator no longer allocated the border color array, it is part of the object now * small memory footprint optimizations in ViewLayer, Decorator and WindowLayer git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22003 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
117b384e5ea73689b02264424911b0848be47962 |
|
27-Jun-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Implemented the overlay suspend/resume protocol on mode changes; not really tested yet. Also, BBitmap::LockBits() should probably fail when the Bits() are NULL. * The downside is that many more classes now know of each other. * Cleaned up the work divided between the BitmapManager and the Overlay class. * Fixed a memory leak in AS_CREATE_BITMAP in case the bitmap could not be added to the ServerApp's bitmap list. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21512 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fe19cff624b39e06a198b5cba0a12d14bd5342bb |
|
04-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
No longer invalidates the view when an overlay bitmap is updated. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17319 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0ac013e66f75c5733fcd6bca47300d126b293279 |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Some refactoring: renamed OverlayCookie to Overlay and put it in its own source file. * An overlay is now also hidden in case its is removed from the window. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7c7883b9f7be15d6ffcc066e0f75e3d878c7923 |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* We now have working video overlay - even though the overlay_token handling is currently broken, mode switches probably fail or result in sudden death (didn't try) it's good enough for Radeon cards and VLC (might work with others as well). * Implemented follow modes for view bitmaps (wasn't taken into account at all before). * Switched to a darker overlay color for now (dunno what exactly makes a good candidate there, but this one is good enough for now). * Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
21c8c925d834845b599781b72192b10befc68ec0 |
|
22-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* With Rudolf's information about relocating overlays, I changed the way memory is managed for those bitmaps: - the shared client memory mechanism is used to allocate a small overlay_client_data structure that contains the actual buffer and a semaphore that you have acquire in order to access it. - LockBits()/UnlockBits() now have a function: you need to call them before accessing the overlay buffer, and you need to keep that lock until you're done with it. * The overlay cookie is now an extra member of the ServerBitmap class. * Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated with the bitmap. * ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay color instead of any contents (this is currently in ugly pink, but will become some dark color later on). * All what's missing from actually being able to use overlays now is to configure them so that they are shown on screen. VLC will now show an empty pink window when overlay video is enabled. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17201 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
68bf2de593715bb0f43a0fbbd988bf9f2d651976 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Refined overlay support a bit: we now allow as many overlay bitmaps to be created as the graphics driver does. * Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected. * We're no longer using the B_OVERLAY_COUNT hook anymore - that one really looks like a misconception to me; I don't see how it can be useful. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17196 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
37b502f28bf22293b4b060e8577e491d1c299ca8 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented some more overlay support - the overlay bitmap is now allocated via the graphics driver (but not yet shown on screen). I probably got the meaning of the "overlay count" wrong - I guess that you can allocate any number of overlay bitmaps, but can only see "overlay count" on screen at a time (right now, I only allow to create "overlay count" bitmaps). Stephan? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17193 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
16ed1e1d15aac69c945890e5d5990bb41d9f4303 |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed headers/private/servers/app - everything is in src/servers/app now. * Removed DisplaySupport.h, wasn't needed anymore. * Removed private color set functions from InterfaceDefs.cpp - we might want something similar, but definitely not like that. * Minor cleanup, added some missing licenses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16831 a95241bf-73f2-0310-859d-f6bbb57e9c96
|