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).
Traditionally, loading a malformed PNG file with
cairo_image_surface_create_from_png() resulted in
CAIRO_STATUS_NO_MEMORY. This was apparently changed in commit
c5ee3f11b5 by adding CAIRO_STATUS_PNG_ERROR and using it for errors
returned from libpng. However, I don't see how this was supposed to
actually work.
There are a couple of error codes supported by
_cairo_surface_create_in_error(). Anything else is turned into
CAIRO_STATUS_NO_MEMORY, which is not a helpful status. For this reason,
CAIRO_STATUS_PNG_ERROR would be turned into CAIRO_STATUS_NO_MEMORY.
This commit adds support for CAIRO_STATUS_PNG_ERROR to
_cairo_surface_create_in_error() so that this error can actually be
returned to the caller.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I added options->variations = strdup("slnt=0,wght=400,wdth=100"); to the
end of _cairo_font_options_init_default(). This makes all font option
objects own some memory that needs to be freed. Then I ran some random
test under valgrind and found memory leaks.
_cairo_surface_copy_similar_properties() gets the font options of a
surface via cairo_surface_get_font_options(). This creates a copy of the
font variations that I added above. _cairo_surface_set_font_options()
then copies this again (it calls _cairo_font_options_init_copy). Thus,
the original copy is still owned by
_cairo_surface_copy_similar_properties() and needs to be freed.
This commit fixes four leaks in "valgrind --leak-check=full
./cairo-test-suite -f leaks-set-scaled-font". A random example is:
25 bytes in 1 blocks are definitely lost in loss record 4 of 25
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4ECBC99: strdup (strdup.c:42)
by 0x4886C0C: _cairo_font_options_init_copy (cairo-font-options.c:99)
by 0x48F1DDE: cairo_surface_get_font_options (cairo-surface.c:1620)
by 0x48F0691: _cairo_surface_copy_similar_properties (cairo-surface.c:454)
by 0x48F087C: cairo_surface_create_similar (cairo-surface.c:528)
by 0x1B168A: _cairo_boilerplate_pdf_create_surface (cairo-boilerplate-pdf.c:92)
by 0x129B7F: cairo_test_for_target (cairo-test.c:824)
by 0x12B37F: _cairo_test_context_run_for_target (cairo-test.c:1545)
by 0x12C385: _cairo_test_runner_draw (cairo-test-runner.c:258)
by 0x12DEB5: main (cairo-test-runner.c:962)
Signed-off-by: Uli Schlachter <psychon@znc.in>
When calling cairo_surface_get_font_options(), a font options instance
is allocated for the surface. Normally, this just initialised some
otherwise uninitialised fields in cairo_surface_t. Since commit
67eeed44, cairo_font_options_t can contain an extra allocation for a
custom palette. Since commit edf9497c3a, cairo_font_options_t can
contain an extra allocation for a string. Before these commit, font
options could just be dropped, but now they need to be freed.
This commit makes cairo_surface_destroy() finish the contained font
options if they were initialised.
I didn't manage to produce a self-contained test case for this leak. I
found it by just looking at the code. However, I found a way to force a
leak: By adding options->variations=strdtup("slnt=0,wght=400,wdth=100");
to the end of _cairo_font_options_init_default(), all font option
instances now cause a leak unless they are finished. With this extra
change, this commit fixes a memory leak that is simply caused by calling
cairo_surface_get_font_options().
Signed-off-by: Uli Schlachter <psychon@znc.in>
The original "slim" symbol rewriting was added without any shred of a
set of performance evaluation, and mostly copy-pasted from a very early
version of pixman. Pixman itself never used them, and most C
libraries—like GLib and GTK—have dropped similar mechanisms over the
past 15 years, as linkers have improved considerably in the meantime.
Modern linkers provide functionality to avoid intra-library PLT jump
through flags like `-Bsymbolic-functions`; we should use that, instead,
and keep the code base more maintainable and debuggable.
A little history digging shows that we only ever had one caller of
_cairo_tee_surface_find_match. Commit 658cdc7c9a "Introduce
cairo_tee_surface_t" added this code to _cairo_surface_clone_similar():
if (src->type == CAIRO_SURFACE_TYPE_TEE) {
cairo_surface_t *match;
match = _cairo_tee_surface_find_match (src,
surface->backend,
content);
if (match != NULL)
src = match;
}
Then, two years later in 2011, commit af9fbd176b "Introduce a new compositor
architecture" removed _cairo_surface_clone_similar() and thus this code became
unused.
This commit drops this unused code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This implements Type 3 color fonts for PDF for any font with a
CAIRO_SCALED_GLYPH_INFO_RECORDING_SURFACE. This includes user-fonts,
SVG fonts, and COLR fonts.
Glyphs with foreground colors are not yet implemented as Type 3 glyphs
and will be rendered as images by cairo-surface.
The surface code was optimizing away show_text_glyphs
based on the operator when the source pattern is clear.
But if we are rendering color glyphs, that is not
correct since we are using the glyphs as source.
When rendering clusters that have colored and non-colored
glyphs, we were falling back to using show_text_glyphs,
rendering all glyphs in the cluster without color.
Instead, make composite_one_color_glyph smart enough
to handle non-color glyphs, and only skip clusters
that are entirely non-color.
Testcase: hb-view AmiriQuranColored.otf -u 627,64e
When the run contains a mix of color and non-color
glyphs, composite_color_glyphs returns the non-color
glyphs unhandled in the same array. In the rtl case,
the glyphs are processed from the end and the unhandled
glyphs are accumulated at the end as well, and we
need to move them to the beginning of the array before
we return. Add the missing memmove call to do that.
Fixes: #533
COLR fonts can have a layer with the same color as the current text
color. This change passes the current color (if solid) through to
the font backend where it can be used to render color fonts.
scaled_glyph_lookup checks if the foreground color has changed (for
glyph that require it) and requests a new color surface if required.
This also fixes a bug where scaled_glyph_lookup would always request a
color surface for glyphs for glyphs in color fonts that do not have
color.
The intention here is: "if show_text_glyphs is unsupported,
try show_gyphs". We need to make sure to set the status to
unsupported before checking it, otherwise we end up looking
at the status that was set by composite_color_glyphs if
show_text_glyphs is NULL.
This showed up in https://github.com/harfbuzz/harfbuzz/issues/2675
In commit 10e58a4a I changed the code in cairo-surface.c to avoid
setting surface->is_clear = FALSE; in some situations where it was not
necessary, because the operation did not actually modify anything (it
returned CAIRO_INT_STATUS_NOTHING_TO_DO). However, that change
accidentally also caused _cairo_surface_paint() not to set
surface->is_clear = TRUE; in similar cases. That was unintended.
This commit fixes that by always setting is_clear = TRUE when necessary,
but keeps the optimisation of not setting is_clear = FALSE when not
necessary.
The connection to the below issue is that the issue happened with
surfaces with width=0. Clearing such a surface with CAIRO_OPERATOR_CLEAR
causes CAIRO_INT_STATUS_NOTHING_TO_DO and thus is_clear = TRUE was not
set. This error was later caught by a failed assertion.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/283
Signed-off-by: Uli Schlachter <psychon@znc.in>
We can't just move around the contents of the
passed-in string, we need to make a copy. This
was showing up as memory corruption in pango.
See https://gitlab.gnome.org/GNOME/pango/issues/346
_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>
When a color glyph is completely clipped away, we
get the non-zero status 'nothing to do'. In that case,
we must not exit early, since there might still be work
to do for the other color glyphs.
This bug was showing up as color glyphs stopping to render
in GTK+ entries that are scrolled to the right, and also
as color glyphs not rendering inside the selection sometimes.
See https://bugzilla.gnome.org/show_bug.cgi?id=790255 and
https://bugzilla.gnome.org/show_bug.cgi?id=788071.
- Restructure the emit_surface code so that mime types are checked first.
- Add a test parameter to emit_surface to test if the surface will be emitted
as an image or recording instead checking the surface type as the attached
mime may override this.
- Mark surface as not clear when mime is attached to avoid optimizing away
"clear" surfaces that have mime attached.
- Include entire surface in analysis if mime attached (also fixes bug with
calculating the extents CONTENT_COLOR surfaces)
PDF XObjects need to specify the bounding box. Emit unbounded surfaces
when finishing as at this point the extents of all uses of the
unbounded surface are known.
This completes the full set of PDF/PS image filters allowing image
data to be passed though without decompressing then recompresssing in
a less efficient format.
The difficulty with CCITT_FAX is it needs some decoding parameters
that are not stored inside the image data. This is achieved by using
an additional mime type CCITT_FAX_PARAMS that contains the params in
key=value format.
In cairo, most operators are composited this way:
((src IN mask) OP dst) LERP_clip dst
but SOURCE and CLEAR operators are composited this way:
(src OP dst) LERP_(clip IN mask) dst
(why is this not specified anywhere in the docs or source tree?)
With color glyphs, we were not special-casing SOURCE and CLEAR.
We do now.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=102661
Do away with the separate check for color glyphs - we can just
do the filtering, and if there are no color glyphs, it is a
no-op. As long as we only do this for fonts with color glyphs,
it should be fine.
Reduce repetition in composite_color_glyphs by breaking out
some helper functions.
