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>
Currently, the pdf-mime-data check just fails for me with the following
output:
sh: 1: pdfimages: not found
pdf-mime-data: FAIL
pdf-mime-data.log contains:
pdfimages failed with exit status 32512
Since I do not have pdfimages installed... yeah.
This commit "fixes" that problem by skipping the test if pdfimages is
not available. No idea if it would pass if it were available, but I do
not feel like installing pdfimages just to test.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the code use the existing helper for loading PNGs that also
considers the $srcdir environment variable. This makes it find the file
in out of tree builds.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I am not quite sure, but an if for "ignore this error if something
failed" seems wrong. Either this should have compared against status2 or
checked for success. This commit fixes the code for the latter.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The test mime-unique-id checks that some images are only embedded once
in a PDF. It does so by checking if the file size is within some
expected bounds. However, the test fails for me because the file is too
small. Yes, too *small*.
Fix this by updating the test to expect my current file size.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of failing because it did not find an image, this now fails for
me since the PDF is too small (???).
This new code is modelled after cairo_test_create_surface_from_png().
Signed-off-by: Uli Schlachter <psychon@znc.in>
Forking a process also duplicates the buffers of FILE*s. Thus, if there
is pending data, both the parent and the child process will write
things. This is seldom a good idea.
This issue was not noticed so far since by default the test suite
already calls fflush() a lot. However, when stdout and stderr are both
not a tty (according to isatty(1) and isatty(2)), these flushes are
skipped. The result is that the child process repeat the full output
from the test suite starting with "Compiled against cairo 1.17.4,
running on 1.17.4."
To reproduce this problem run: ./cairo-test-suite 2>&1 | cat
Fix this by flushing all the files that I managed to find before fork().
Thanks to Pekka Paalanen for helping me figure this out.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Once upon a time, automake had one way to run tests. Apparently this is
(nowadays?) called the serial test harness. Then, in some release (I do
not remember which one), the parallel test harness became the default.
The parallel harness runs all tests in parallel, but does not (really)
show the test output, but instead has output redirected to files. Sort
of. I did not find the result of my printf() anywhere.
The automake docs strongly discourage using the serial test harness [0],
but do not really say why. For cairo, I do not see problems:
We have some quick, small checks (e.g. is cairo_public used where needed
in the public headers). And then there is the big, heavy-weight test
suite (cairo-test-suite). Thus, running these things in parallel has
basically no benefits.
Additionally, cairo-test-suite takes really, really long. Not seeing any
output while it is running is annoying. Failing to find the output even
in files is bad.
Thus, since I do not see any benefits and only downsides to the parallel
test harness, this commit switches to the serial one.
[0]: https://www.gnu.org/software/automake/manual/html_node/Serial-Test-Harness.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
libspectre is only used for ps tests. Adding it to "deps" needlessly
makes it show up in cairo.pc's Requires.private.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/425
Signed-off-by: Uli Schlachter <psychon@znc.in>
The run check is particularly annoying in cross-compile scenarios,
so allow bypassing the check by having the user provide the value
via a cross file or native file:
[properties]
ipc_rmid_deferred_release = true
Closes#408
When declaring a dependency on a feature, say `dependency('cairo-png')`
the resulting object did not depend on cairo and thus was missing
basic things like, `cairo.h` from its include dir.
Make it so overrides do in fact include the basic cairo functionality
needed for them to work.
Related:
https://gitlab.freedesktop.org/gstreamer/gst-devtools/-/merge_requests/236
Fixes errors such as
Traceback (most recent call last):
File "C:\Users\...\cairo\test\make-cairo-test-constructors.py", line 19, in <module>
for l in f.readlines():
File "c:\python39\lib\encodings\cp1253.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x98 in position 6694: character maps to <undefined>
on non-English-language Windows locales/installations.
Doesn't build any more, is very much non-essential, and hasn't
been touched in any meaningful way since it was added 13 years
ago, so just remove it for now until someone steps up. Chances
are the glibc version has improved since then.
And update configure/meson checks to check for the new function.
Drop libiberty.h check since it's only needed by backtrace-symbols.c
which we're about to remove.
Closes#391, #460
The documentation for _cairo_array_append_multiple says "one or more items".
If it is called with num_elements=0, it ends up calling _cairo_array_grow_by
with num_elements=0, which if the array is currently empty (as here) leads
to undefined behavior in _cairo_array_allocate in the line
*elements = array->elements + array->num_elements * array->element_size;
because it ends up trying to add 0 to a null pointer. C doesn't allow this.
(UBSan flags this as "applying zero offset to null pointer".)
