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>

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>

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.)

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.

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.

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.

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.

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.

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.

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

* Implemented deleting completely empty chunks.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39598 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 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

* Cleanup, no functional change.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39438 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 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

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

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

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

* 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

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.

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.

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.

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.

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.

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

* Implemented deleting completely empty chunks.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39598 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 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

* Cleanup, no functional change.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39438 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 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

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

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

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

* 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