#
60d30785 |
|
27-Aug-2020 |
X512 <danger_mail@list.ru> |
app_server memory management fixes: use BReference Use BReference for more automated reference counting in app_server, fixing some use-after-free and other problems. Extracted from https://review.haiku-os.org/c/haiku/+/2695 Change-Id: I141bb248229405896b29feff3338447f7257b0b4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
6331a6bd |
|
08-Mar-2013 |
Axel Dörfler <axeld@pinc-software.de> |
app_server: The client memory allocator is now reference counted. * Not sure if cursors could also have triggered this, but the memory allocator can now outlive its ServerApp. * However, this may also reveal cases of memory that is not freed correctly.
|
#
4f96ace6 |
|
02-Apr-2013 |
Axel Dörfler <axeld@pinc-software.de> |
app_server: detach client allocator on quit. * This prevents sending out notification to applications that are already gone, and should thus fix #9116 according to John.
|
#
7705d517 |
|
29-Apr-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Lock in ClientMemoryAllocator::Allocate(), and Free(). * Since bitmaps are reference counted, it might not be easy (and already not the case) that holding the ServerApp lock can be enforced. * To be on the safe side, allocations and freeing memory now performs its own locking. * Brought the documentation to the status quo.
|
#
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
|
#
1d219b3a |
|
15-Nov-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Added AS_DUMP_ALLOCATOR command that dumps an applications memory allocator to the syslog/serial output. * Added app_server_debug command that currently just sends this command to the specified teams. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39441 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
da6b5d6d |
|
15-Nov-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Cleanup, no functional change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39438 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9a44fdc9 |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Implemented a new client allocation method: instead of having all bitmaps of all teams in serveral server areas, and instead of having to eventually clone them all several times in BBitmap, we now have one or more areas per team, and BBitmap will only clone areas once if needed. As a side effect, this method should be magnitudes faster than the previous version. * This method is also much more secure: instead of putting the allocation maintenance structures into those everyone-read-write areas, they are now separated, so that faulty applications cannot crash the app_server this way anymore. This should fix bug #172. * Freeing memory is not yet implemented though! (although all memory will be freed upon app exit) * There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator (ie. via ServerApp), per area (for overlays, not yet implemented), and using malloc()/free() for server-only bitmaps. * ServerBitmap now deletes its buffers itself. * Cleaned up BBitmap and BApplication a bit. * The test environment currently doesn't build anymore, will fix it next. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4f96ace6d567f266b7ce7f13eed7ed6f0a594f05 |
|
02-Apr-2013 |
Axel Dörfler <axeld@pinc-software.de> |
app_server: detach client allocator on quit. * This prevents sending out notification to applications that are already gone, and should thus fix #9116 according to John.
|
#
7705d517d115db04ad69e78104755cc65ec33336 |
|
29-Apr-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Lock in ClientMemoryAllocator::Allocate(), and Free(). * Since bitmaps are reference counted, it might not be easy (and already not the case) that holding the ServerApp lock can be enforced. * To be on the safe side, allocations and freeing memory now performs its own locking. * Brought the documentation to the status quo.
|
#
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
|
#
1d219b3a253f44d73aa68cd42238d6fa451bb80e |
|
15-Nov-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Added AS_DUMP_ALLOCATOR command that dumps an applications memory allocator to the syslog/serial output. * Added app_server_debug command that currently just sends this command to the specified teams. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39441 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
da6b5d6d3f8b4528cc6d67c0309df9da25527788 |
|
15-Nov-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Cleanup, no functional change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39438 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9a44fdc97c4c91b6be039ac5125a618c8fd268cc |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Implemented a new client allocation method: instead of having all bitmaps of all teams in serveral server areas, and instead of having to eventually clone them all several times in BBitmap, we now have one or more areas per team, and BBitmap will only clone areas once if needed. As a side effect, this method should be magnitudes faster than the previous version. * This method is also much more secure: instead of putting the allocation maintenance structures into those everyone-read-write areas, they are now separated, so that faulty applications cannot crash the app_server this way anymore. This should fix bug #172. * Freeing memory is not yet implemented though! (although all memory will be freed upon app exit) * There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator (ie. via ServerApp), per area (for overlays, not yet implemented), and using malloc()/free() for server-only bitmaps. * ServerBitmap now deletes its buffers itself. * Cleaned up BBitmap and BApplication a bit. * The test environment currently doesn't build anymore, will fix it next. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|