To avoid any possibility of uninitialized memory.
The exceptions are:
- where the allocation is immediately overwritten by a memcpy or struct copy.
- arrays of structs to avoid any performance impact (except when the
array is returned by the public API).
_cairo_malloc(0) always returns NULL, but has not been used
consistently. This patch replaces many calls to malloc() with
_cairo_malloc().
Fixes: fdo# 101547
CVE: CVE-2017-9814 Heap buffer overflow at cairo-truetype-subset.c:1299
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
We merge _cairo_surface_create_similar_scratch and
_cairo_surface_create_similar_solid into a single function named
_cairo_surface_create_scratch, to avoid confusion with
cairo_surface_create_similar which now will have a different
behaviour wrt the sizes and the device-scale.
_create_scratch assumes the width and height are in backend
coordinates, while create_similar does not.
_cairo_surface_subsurface_set_snapshot () sets the subsurface as the
snapshot of its target. This creates a reference cycle (as the target
is already referenced by the surface) and thus a memory leak (assuming
the likely case that user doesn't call finish).
Test case: subsurface-similar-repeat.
So make this call as a no-op for the time being until the bug is fixed.
In order to prevent a race between concurrent destroy and use in another
thread, we need to acquire a reference to the snapshot->target under a
mutex. Whilst we hold that reference, it prevents the internal destroy
mechanism from freeing the memory we are using (if we have a pointer to
the original surface) and the client drops their final reference.
Oh boy, talk about opening a can of worms...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When cairo_surface_create_for_rectangle() is given non-integer parameters,
the subsurface's size may be negative(e.g x = 0.2, width = 0.7, the
final width will be -1). This illegal surface may cause crash somewhere
upon later use, and although the fractional subsurface is ill-defined,
we should never crash!
I need to remember that the translation for the pattern matrix is the
inverse of the translation for drawing.
Fixes: subsurface-modify-parent
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only allow one owner to keep their snapshot on the subsurface, and
so automatically replace any previous snapshot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Following the previous commit, we only allocate a simple image when
acquiring the source so we only need to unreference it upon release.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove all of the special casing and simply extract the source. The time
for special casing is to avoid calling the generic acquire in the first
place, so kiss.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
Ouch, a nasty bug surfaces after rearranging code to fix the others.
Another self-copy loop this time through a subsurface of a recording
surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And not the backend directly as this bypasses the extra steps taken in
the higher level to do common actions such as detach snapshots.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adrian Johnson found that I had broken show_page() and pinpointed the
cause to being that cairo_show_page() was being called on the recording
surface and not the pagination surface after my overhaul for
cairo_backend_t. In fact, the problem was far more severe as the mistake
caused the created context to point to the wrong surface entirely,
bypassing the surface proxy.
What is desired is for the proxy's target surface to choose what manner
of context is should use, but for all calls into the surface backend to
go through the proxy surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code is passing in the extra info received from
the target surface's acquire_source() method to
_cairo_surface_get_extents() rather than the acquired
source surface itself.
Whenever subsurface extents are not contained in the target extents,
using the source image given by the target (with origin corrected by
using an appropriate offset in the data pointer) is not a valid
operation. Fallback to cloning in that case.
Do not try to hide being a subsurface.
This would cause confusion when users where calling surface-type
specific getters on subsurfaces.
FIXME: We still need public API to access a subsurface's target though.
