The g_memdup() function has been deprecated, as it takes the size of the
memory area as an unsigned integer. The g_memdup2() replacement uses the
more appropriate size_t type, instead.
This adds the necessary commands to run the test suite on MacOS in CI
and to also ignore the current failures.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The create-for-stream test verifies that writing something to a file and
writing it to an in-memory surface produces the same output. The test
currently fails when the svg backend is tested with:
TEST: create_for_stream TARGET: pdf RESULT: PASS
svg: Stream based output differ from file output for output/create-for-stream.out.svg.
TEST: create_for_stream TARGET: svg RESULT: FAIL
I guess this is because svg uses unique IDs for surfaces, meaning that
drawing two times the same thing in the same process can produce
different outputs. However, this is just a guess and I didn't
investigate further.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a special hack to the test suite to ignore the crashes for
self-copy and self-copy-overlap for the svg backend in CI.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This hopefully fixes the raster-source test case crashing:
cairo-svg-surface.c:2269: _cairo_svg_surface_emit_pattern: Assertion `!"reached"' failed.
I cannot / did not test this change locally and rely on CI to tell me
whether this works.
Signed-off-by: Uli Schlachter <psychon@znc.in>
From config.log from CI:
configure:27855: $PKG_CONFIG --exists --print-errors "$librsvg_DEPENDENCY gdk-2.0"
Package gdk-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gdk-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gdk-2.0', required by 'virtual:world', not found
configure:27858: $? = 1
Package 'gdk-2.0', required by 'virtual:world', not found
configure:27885: result: no
configure:27921: WARNING: SVG backend will not be tested since librsvg >= 2.35.0 is not available
According to Google, it seems like gtk2-devel is the right package to
get gdk-2.0.pc.
Thanks a lot to @tpm for explaining that I also have to change the TAG
variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fail is not large, so doesn't "cost much", but it helps in figuring
out build problems in CI like "what exactly is missing for the SVG
backend?".
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a new mechanism to mark tests as expected to fail via
an environment variable. For example, if you expect the tests "foo" and
"bar" to fail when run under image.argb32, you would set
CAIRO_TEST_IGNORE_image_argb32=foo,bar
The test suite then expects these tests to fail and treats this as
xfail. If they do not fail, this is a failure on its own.
This new feature is explicitly not documented much, because it is only
used as a stopgap measure to make our CI more useful: Right now the test
suite runs on CI, but the result is ignored. This new feature allows to
mark the known failures as xfail without too much work. When the
situation changes, this will be noticed as a new test suite failure.
Thus, these environment variables to not run into the danger of still
containing tests that were already fixed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should allow to use them for allocating large amounts of memory.
Also use explicit checks for zeros to not make the compiler think that it is a boolean context.
This function parses some raw font data and it trusts the font to be
well-formed. This means that a font can just say "this segment is a
gigabyte large" and the code will happily jump ahead in memory. Bad
things then happen in practice.
Fix this by adding lots of bounds check.
Also, an existing bounds check makes sure we are still before the end of
the data, but then happily reads the next six bytes. Fix this by making
sure we actually have six bytes of data.
No regression test since the last few times I tried to do this for font
issues, I ended up with a large/huge blob of font data. Too large for
the test suite.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27969
Signed-off-by: Uli Schlachter <psychon@znc.in>
Install with exec flag set and make sure tool is
executable in build directory as well (by making
the input file in the source directory executable).
Fixes#462
Tested with valgrind. Before this patch, I got the following "definitely
lost" entry, which is gone afterwards:
94,416 bytes in 1 blocks are definitely lost in loss record 427 of 427
at 0x483877F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4B053F8: cairo_truetype_font_write_glyf_table (cairo-truetype-subset.c:625)
by 0x4B06219: cairo_truetype_font_generate (cairo-truetype-subset.c:991)
by 0x4B06917: cairo_truetype_subset_init_internal (cairo-truetype-subset.c:1159)
by 0x4B06D72: _cairo_truetype_subset_init_pdf (cairo-truetype-subset.c:1255)
by 0x4B6B113: _cairo_pdf_surface_emit_truetype_font_subset (cairo-pdf-surface.c:5892)
by 0x4B6C2AD: _cairo_pdf_surface_emit_unscaled_font_subset (cairo-pdf-surface.c:6366)
by 0x4B02FC7: _cairo_sub_font_collect (cairo-scaled-font-subsets.c:741)
by 0x4B03A7A: _cairo_scaled_font_subsets_foreach_internal (cairo-scaled-font-subsets.c:1062)
by 0x4B03B21: _cairo_scaled_font_subsets_foreach_unscaled (cairo-scaled-font-subsets.c:1090)
by 0x4B6C3ED: _cairo_pdf_surface_emit_font_subsets (cairo-pdf-surface.c:6412)
by 0x4B62B1A: _cairo_pdf_surface_finish (cairo-pdf-surface.c:2222)
To reproduce, run the test case from the below link.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28023
Signed-off-by: Uli Schlachter <psychon@znc.in>
