#
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>
|
#
2afe4c52 |
|
26-Jan-2020 |
Murai Takashi <tmurai01@gmail.com> |
appserver: Fix PVS V595 Add NULL check for fAllocator, since it might return NULL. Change-Id: Ifb72266b4d4c5f076f0c663066dc9b81e94fc201 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2162 Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
|
#
23121bac |
|
10-Aug-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
app_server: Set B_CLONEABLE_AREA where applicable. This is all that is needed to boot a minimum image with userland area cloning protections enabled (media_server is not included in such builds.)
|
#
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.
|
#
3fed1a15 |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
8e2140fa |
|
29-Apr-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Fixed a large client side memory leak for app_server memory. * The areas allocated for BBitmaps were never deleted, even though the app_server deleted its part when the memory got freed. * This resulted in a constant memory increase if the application in question would operate on many changing large bitmaps, like photos. * Since the bitmaps are reference counted, we don't actually know when to delete the areas, so that the app_server now notifies the client whenever that is possible. * This might fix #6824.
|
#
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.
|
#
6068e439 |
|
28-Apr-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Optimized freeing client memory if it spans the whole area. * If a block of client memory spans the whole chunk, there is no need to walk the free list for adjacent blocks to join. * Minor cleanup.
|
#
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
|
#
ee72532a |
|
23-Nov-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Implemented deleting completely empty chunks. * Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39598 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
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
|
#
1e855c37 |
|
12-Apr-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Patch by Fredrik Ekdahl: gcc 4 build fixes (missing headers). * Added missing header for mountvolume. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30135 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6a05ab01 |
|
22-Jul-2007 |
Axel Dörfler <axeld@pinc-software.de> |
My ClientMemoryAllocator implementation wasn't complete and badly leaked memory. It now at least frees all memory when the object is deleted. Reported by Jonas - thanks! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21687 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bc9902cf |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented freeing of blocks, though it's not very efficient yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16833 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
04768381 |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
The test environment should now build okay again, as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16829 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.
|
#
3fed1a15f58e8d6fe6b492f3b94bb3625ffeddbd |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
8e2140fa5eb8a019a5134ce041499d14b7ced7a3 |
|
29-Apr-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Fixed a large client side memory leak for app_server memory. * The areas allocated for BBitmaps were never deleted, even though the app_server deleted its part when the memory got freed. * This resulted in a constant memory increase if the application in question would operate on many changing large bitmaps, like photos. * Since the bitmaps are reference counted, we don't actually know when to delete the areas, so that the app_server now notifies the client whenever that is possible. * This might fix #6824.
|
#
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.
|
#
6068e439237ee80ed675fb1deb255de6cb252a6f |
|
28-Apr-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Optimized freeing client memory if it spans the whole area. * If a block of client memory spans the whole chunk, there is no need to walk the free list for adjacent blocks to join. * Minor cleanup.
|
#
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
|
#
ee72532a7af516143c7e4827b1786ab533ca2831 |
|
23-Nov-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Implemented deleting completely empty chunks. * Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39598 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
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
|
#
1e855c376c4f785f926c0c4d4d08c827c05da643 |
|
12-Apr-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Patch by Fredrik Ekdahl: gcc 4 build fixes (missing headers). * Added missing header for mountvolume. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30135 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6a05ab018659e89d713b5a1cef41f4798bdd90de |
|
22-Jul-2007 |
Axel Dörfler <axeld@pinc-software.de> |
My ClientMemoryAllocator implementation wasn't complete and badly leaked memory. It now at least frees all memory when the object is deleted. Reported by Jonas - thanks! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21687 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bc9902cf987b6849fc340b5c4c693798f7c6591e |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented freeing of blocks, though it's not very efficient yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16833 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0476838149c4b599a8c36690ed34595d7965f88f |
|
18-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
The test environment should now build okay again, as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16829 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
|