Extend the "pdf-tagged-text" test so that it does some basic checks
on the PDF file it creates. This covers the date fields as well as
some other metadata. More checks can and should be added.
The code was copying from the wrong member of an union. This caused a
huge num_dashes value to be read, which then caused a so large memory
allocation that malloc returned an error.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/448
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in cairo-cff-subset.c parses a binary font format without
seeming to bother much verifying the data. The result is that poppler
can be used to cause an out-of-bounds access in
cairo_cff_parse_charstring() via a crafted font file. Fix this by adding
the needed length check.
The other code in the file also contains lots of similar things. Since I
cannot really fix everything properly, I'll just fix the one instance
that was found by a fuzzer.
No testcase is added, because this depends on a broken font that is
quite large. Adding something this big to the test suite does not seem
sensible.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/444
Signed-off-by: Uli Schlachter <psychon@znc.in>
The xml surface depends on png. Before this commit, configuring with
autogen.sh --disable-png --disable-svg --enable-xml resulted in a
failing build:
src/cairo-xml-surface.c: In function ‘_cairo_xml_emit_image’:
src/cairo-xml-surface.c:673:14: error: implicit declaration of function
‘cairo_surface_write_to_png_stream’
After this commit, configure instead rejects this combination with:
checking whether cairo's xml surface backend feature could be enabled... no (requires --enable-png)
configure: error: xml surface backend feature could not be enabled
Noticed-at: https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/67#note_644347
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code here temporary replaces extents->clip with another clip to call
a function. Afterwards, it restores the previous copy. The temporary
clip is only freed when it still is pointed to by extents->clip.
This logic is wrong. It is indeed possible that the clip is simplified
and changes. In this case, the original clip is also correctly freed.
However, this still means that we have to clean up and destroy the new
clip. The previous code just leaked it.
This was originally identified by Massimo in [1]. I am just committing
his patch.
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=91267
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/24
Signed-off-by: Uli Schlachter <psychon@znc.in>
This gets rid of the following two leaks reported by valgrind when successfully
running a test with CAIRO_TEST_TARGET=xcb:
8,000 bytes in 2 blocks are definitely lost in loss record 9 of 10
at 0x483877F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4B7E135: read_packet (xcb_in.c:259)
by 0x4B7E135: _xcb_in_read (xcb_in.c:1031)
by 0x4B7BF8E: _xcb_conn_wait (xcb_conn.c:516)
by 0x4B7D6AE: wait_for_reply (xcb_in.c:516)
by 0x4B7D8C8: xcb_request_check (xcb_in.c:745)
by 0x18D747: _cairo_boilerplate_xcb_create_surface (cairo-boilerplate-xcb.c:310)
by 0x12906F: cairo_test_for_target (cairo-test.c:819)
by 0x12AAB5: _cairo_test_context_run_for_target (cairo-test.c:1555)
by 0x126921: _cairo_test_runner_draw (cairo-test-runner.c:250)
by 0x126921: main (cairo-test-runner.c:932)
8,000 bytes in 2 blocks are definitely lost in loss record 10 of 10
at 0x483877F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4B7E135: read_packet (xcb_in.c:259)
by 0x4B7E135: _xcb_in_read (xcb_in.c:1031)
by 0x4B7BF8E: _xcb_conn_wait (xcb_conn.c:516)
by 0x4B7D6AE: wait_for_reply (xcb_in.c:516)
by 0x4B7D7C0: xcb_wait_for_reply (xcb_in.c:546)
by 0x18D45D: find_depth (cairo-boilerplate-xcb.c:154)
by 0x18D45D: _cairo_boilerplate_xcb_create_render_0_0 (cairo-boilerplate-xcb.c:621)
by 0x12906F: cairo_test_for_target (cairo-test.c:819)
by 0x12AAB5: _cairo_test_context_run_for_target (cairo-test.c:1555)
by 0x126921: _cairo_test_runner_draw (cairo-test-runner.c:250)
by 0x126921: main (cairo-test-runner.c:932)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, running the test suite against a non-existing
display under valgrind resulted in:
$ ( cd test; DISPLAY=:2 CAIRO_TEST_TARGET=xcb valgrind --leak-check=full .libs/cairo-test-suite -f random-clip )
[...]
==47359== 64 bytes in 2 blocks are definitely lost in loss record 1 of 7
==47359== at 0x483AB65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==47359== by 0x18A272: cairo_boilerplate_xcalloc (cairo-boilerplate-system.c:65)
==47359== by 0x18D652: _cairo_boilerplate_xcb_create_surface (cairo-boilerplate-xcb.c:269)
==47359== by 0x12906F: cairo_test_for_target (cairo-test.c:819)
==47359== by 0x12AAB5: _cairo_test_context_run_for_target (cairo-test.c:1555)
==47359== by 0x126921: _cairo_test_runner_draw (cairo-test-runner.c:250)
==47359== by 0x126921: main (cairo-test-runner.c:932)
This commit fixes that by freeing the allocated memory in the error
path.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since we now copy the data that CGImage needs we don't need to
keep the surface around anymore, nor release it or the image in the
DataProviderReleaseCallback.
This fixes a typo wherein both a return character and a tab character
were encoded when only a return character was specified for encoding.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
Operators BlueValues, OtherBlues, FamilyBlues, FamilyOtherBlues,
StemSnapH and StemSnapV have operands of type delta which can be
a number or an array of delta-encoded numbers. This array can be
empty according to freetype developers.
This commit checks whether current operator is among those listed
and permits empty operand in such case.
This fixes a typo wherein both a return character and a tab character
were encoded when only a return character was specified for encoding.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
Operators BlueValues, OtherBlues, FamilyBlues, FamilyOtherBlues,
StemSnapH and StemSnapV have operands of type delta which can be
a number or an array of delta-encoded numbers. This array can be
empty according to freetype developers.
This commit checks whether current operator is among those listed
and permits empty operand in such case.
