The LibreOffice project builds Cairo with -DCAIRO_NO_MUTEX.
IMHO that's quite risky for big projects where you don't
control all the code that uses Cairo, but I assume they know
what they're doing.
This change should have been part of commit 87f7c60bf7, but
admittetly CAIRO_NO_MUTEX builds are not actively tested.
Fixes#921
lzo_uint is a typedef for a machine-sized unsigned integral.
We track sizes using unsigned long, which is machine-sized
on most (all?) Unices, but 32bit on 64bit Windows.
This means that lzo_uint and unsigned long are not really
interchangeable (should have used size_t!). Fix the build
by using intermediate variables. The cairo-script file format
ensures that uncompressed data fits within 4GB.
Fixes -Wincompatible-pointer-types errors.
Support for __uint128_t in CLangCL is currently broken [1].
Avoid using that type for now.
As of today MSVC doesn't support 128-bit integral types;
with this change we get feature-parity between MSVC and
CLangCL, so this shouldn't be a problem.
References:
* Clang-cl generates a call to an undefined symbol __udivti3
https://github.com/llvm/llvm-project/issues/25679
"Placeholder" scaled fonts created temporarily by cairo-user-font.c never
get to have an original_font_face (that is, it's always NULL). This breaks
the font-map mapping. Also check the implementation font-face.
Fixes#876
Lifetimes are tied to the DLL so callers cannot extend it anyway
This also helps with performance a tiny bit by removing unneeded
atomic increments / decrements which can churn CPU caches in multi-
threaded scenarios.
This fixes two issues:
1. A global IWICImagingFactory interface pointer was used directly from
any apartment without marshaling. This goes against the rules of COM,
and for all we know could lead to threading issues (perhaps it's not
a problem in practice, but can't tell).
2. The COM apartment where the IWICImagingFactory is created could be
finalized by the user. We take a reference on the STA but the thread
could terminate. If the thread is on the MTA we don't take a reference
at all. In such case the interface pointer would not be valid anymore
(per the COM rules), but most importantly the WIC DLL is unloaded
(this actually happens).
To avoid that we create a IWICImagingFactory transiently each time we
need it.
We could cache the interface pointer using something like IInitializeSpy
or the COM static store [1]. However performance is still great and we'll
likely drop use of WIC soon (see MR !607).
References:
1. The COM static store, part 1: Introduction
https://devblogs.microsoft.com/oldnewthing/20210208-00/?p=104812
It's possible for a pool allocation to fail under glitter_scan_converter_add_edge,
in which case longjmp will be called to bail out, but the converter's jmp_buf
hasn't been appropriately initialized to catch the error.
The new function check if the protected resource was initialized
or not. It's meant for cleanup on explicit module unload (dlclose
or FreeLibrary), where there can't be concurrent code using the
module anymore
Make sure surface->object_stream.stream is cleaned up even if things
failed
In poppler oss-fuzz tests we are getting this leak reported
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x5747417eabd9 in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:74:3
#1 0x574742706f5b in _cairo_memory_stream_create cairo/src/cairo-output-stream.c:741:14
#2 0x5747426757b8 in _cairo_pdf_surface_open_object_stream cairo/src/cairo-pdf-surface.c:2307:34
#3 0x57474266b880 in _cairo_pdf_surface_finish cairo/src/cairo-pdf-surface.c:2700:14
#4 0x57474261afc6 in _cairo_surface_finish cairo/src/cairo-surface.c:1043:11
#5 0x57474261afc6 in cairo_surface_finish cairo/src/cairo-surface.c:1092:5
#6 0x57474270808a in _cairo_paginated_surface_finish cairo/src/cairo-paginated-surface.c:215:2
#7 0x5747426175c2 in _cairo_surface_finish cairo/src/cairo-surface.c:1043:11
#8 0x5747426175c2 in cairo_surface_destroy cairo/src/cairo-surface.c:978:2
This fixes it.
_cairo_pdf_surface_finish was succeeding past
_cairo_pdf_surface_open_object_stream that allocates surface->object_stream.stream,
failing when calling _cairo_pdf_surface_emit_font_subsets
and that memory was never freed
Otherwise gitlab-runner prints a few warnings:
> Uploading artifacts...
> WARNING: Part of .git directory is on the list of files to archive
> WARNING: This may introduce unexpected problems
Both system() and popen() invoke the shell. Which shell is
invoked depends on the COMSPEC environment variable, but
usually it's CMD.exe.
CMD.exe doesn't quite like paths with forward slashes in its
command-line. Most of the times, the forward slash is mistaken
for a command line switch (the start of an option). For example:
cmd /c "dir C:\Windows" works
cmd /c "dir C:/Windows" doesn't work
Open the pipe in binary mode on Windows to get the expected
byte counts. Note that the 'b' mode for popen is not portable
and so is used only on Windows:
> The behavior of popen() is specified for values of mode of "r",
> "w", "re", and "we". Other modes such as "rb" and "wb" might be
> supported by specific implementations, but these would not be
> portable features.
https://pubs.opengroup.org/onlinepubs/9799919799/functions/popen.html
