I hit the problem with _cairo_arc_in_direction() failing the
angle_max >= angle_min assertion earlier this year when using
Thunderbird on openSUSE Tumbleweed. Thunderbird would crash
when rendering some (but not all) HTML email due to this
assert. For some reason, one of the angles passed in was
NaN. Making _cairo_arc_in_direction() return immediately if
either angle is not finite fixed the problem for me, but I
don't know enough about the internals of Cairo to know if
this is, strictly speaking, the "right" fix. Also, having
tested again today _without_ this change applied, I am now
no longer able to reproduce the problem :-/ I still have the
same version of Cairo installed (1.17.8), but various other
packages on that system have been updated in the meantime,
so maybe that's a factor. Or maybe I'm just lucky and
haven't hit a "bad" HTML email this time...?
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/352
Signed-off-by: Tim Serong <tserong@suse.com>
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.
This commit makes the script surface finish the font options that it
contains. This fixes the following valgrind report:
25 bytes in 1 blocks are definitely lost in loss record 8 of 21
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4ECBC99: strdup (strdup.c:42)
by 0x4886B7F: _cairo_font_options_init_default (cairo-font-options.c:86)
by 0x49768F4: _cairo_script_implicit_context_init (cairo-script-surface.c:3676)
by 0x4976B22: _cairo_script_surface_create_internal (cairo-script-surface.c:3733)
by 0x4976EA1: cairo_script_surface_create (cairo-script-surface.c:3962)
by 0x1B0A97: _cairo_boilerplate_script_create_surface (cairo-boilerplate-script.c:63)
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>
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>
A scaled font contains font options. Since commit 67eeed44, this can
contain an extra allocation for a custom palette. Since commit
edf9497c3a, this contains 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 the relevant code for creating and finishing scaled
fonts also clean up the font options.
The test added in the previous commit also hits this bug (I only found
these leaks accidentially!). Running "valgrind --leak-check=full
./cairo-test-suite -f leaks-set-scaled-font" no longer reports the following
after this change:
40 bytes in 1 blocks are definitely lost in loss record 1 of 11
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x48DAFFB: _cairo_scaled_font_init_key (cairo-scaled-font.c:675)
by 0x48DC077: cairo_scaled_font_create (cairo-scaled-font.c:1096)
by 0x15BF08: leaks_set_scaled_font (leaks.c:43)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
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)
40 bytes in 1 blocks are definitely lost in loss record 2 of 11
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x49337BB: _cairo_ft_font_face_scaled_font_create (cairo-ft-font.c:2073)
by 0x48DC340: cairo_scaled_font_create (cairo-scaled-font.c:1176)
by 0x15BF08: leaks_set_scaled_font (leaks.c:43)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
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)
40 bytes in 1 blocks are definitely lost in loss record 3 of 11
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x48DB280: _cairo_scaled_font_init (cairo-scaled-font.c:742)
by 0x4933804: _cairo_ft_font_face_scaled_font_create (cairo-ft-font.c:2076)
by 0x48DC340: cairo_scaled_font_create (cairo-scaled-font.c:1176)
by 0x15BF08: leaks_set_scaled_font (leaks.c:43)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
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>
cairo_gstate_t contains a cairo_font_options_t. Since commit 67eeed44,
this can contain an extra allocation for a custom palette. Since commit
edf9497c3a, this contains 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_gstate_fini() finish the font options to free
the memory allocation.
The new test was run via "valgrind --leak-check=full ./cairo-test-suite
-f leaks-set-scaled-font". The following reported leak goes away thanks
to this commit:
1,040 bytes in 26 blocks are definitely lost in loss record 6 of 12
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4886C62: _cairo_font_options_init_copy (cairo-font-options.c:105)
by 0x488C029: _cairo_gstate_set_font_options (cairo-gstate.c:1757)
by 0x48841D7: _cairo_default_context_set_scaled_font (cairo-default-context.c:1310)
by 0x490809A: cairo_set_scaled_font (cairo.c:3318)
by 0x15BF1F: leaks_set_scaled_font (leaks.c:45)
by 0x129EF0: cairo_test_for_target (cairo-test.c:938)
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)
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/795
Signed-off-by: Uli Schlachter <psychon@znc.in>
../src/cairo-pdf-surface.c: In function '_cairo_pdf_surface_open_content_stream':
../src/cairo-pdf-surface.c:2537:45: error: format not a string literal and no format arguments [-Werror=format-security]
2537 | str);
| ^~~
cc1: some warnings being treated as errors
The master/slave terms are both inappropriate and inaccurate: the tee
surface replicates the rendering commands from a primary surface to
other surfaces.
This change is a mechanical search-and-replace.
We should default on every platform we care about to hidden symbols, to
avoid leaking private symbols.
On Windows this is the default state of affairs with the MSVC toolchain;
with GCC and GCC-compatible toolchains, we need to opt into this
behaviour. Luckily for us, Cairo already has an annotation for public
symbols, so we can easily tweak it to include the visibility attribute.
When building ancillary libraries as part of the Cairo compilation on
Windows, we use a pre-processor symbol to ensure that we keep the
dllexport annotation. This avoids including the cairoint.h header file.
Fixes: #582
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.
Andreas Falkenhahn reported the issue below and indicated that the color
channels are swapped. This commit fixes the byte swap.
The problem is that be32_to_cpu() is a no-op on big endian systems.
However, we also have a bswap_32() function available that always works.
Testing done: None by me, but Andreas Falkenhahn reported that his patch
fixes colors on a PowerPC system.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/787
Signed-off-by: Uli Schlachter <psychon@znc.in>
This was found while debugging why The Twemoji Mozilla
font renders a white-on-while in pango.
We need to call _render_glyph_bitmap, since we want
FT_Render_Glyph to handle the COLRv0 layers for us.
cairo_win32_font_face_create_for_hfont is reusing the HFONT object
passed by an argument if possible to create a scaled font. However,
the condition was wrong. It checked the font matrix scale factor is
`-lfHeight`. But it should be `-lfHeight * WIN32_FONT_LOGICAL_SCALE`.
Fixescairo/cairo#3
As we do already in _cairo_recording_surface_finish. Otherwise, the
cleanup path of _cairo_recording_surface_create_bbtree() could call
free() on surface->bbtree which is not dynamically allocated.
Closes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/645
The following clipping text tests of win32/rgb24 target were visibly
failing because clipping didn't work.
* clip-text
* partial-clip-text-bottom
* partial-clip-text-left
* partial-clip-text-right
* partial-clip-text-top
_cairo_win32_gdi_compositor_glyphs sets the clip. However,
_cairo_dwrite_show_glyphs_on_surface unset it.
Fixescairo/cairo#641
The DWRITE_COLOR_GLYPH_RUN1 struct definition of the old MinGW
dwrite_3.h was invalid. To work around the problem, dw-extra.h defined
the correct struct definition and all necessary API from dwrite_3.h.
This approach needed to redefine all necessary API.
This change added DWRITE_COLOR_GLYPH_RUN1_WORKAROUND struct and use it
for IDWriteColorGlyphRunEnumerator1::GetCurrentRun.
