unusedcode.easy is generated via callcatcher[1] and filtered to remove some tricky edge-cases (see Makefile), e.g. anything which could plausibly be dlsymed or any symbol defined in an external library bundled into LibreOffice which doesn't happen to get used by LibreOffice. unusedcode.easy is generated on an x86_64 --enable-debug --enable-dbgutil configuration. Code listed as unused is code that gcc outputs but that nothing calls (or takes the address of). a) It's possible that some other platform or configuration uses the code, so manual inspection is always required. b) At the time of writing the majority of unused code now originates via macros, mostly from pre-STL containers, see [2] for killing two birds with one stone. These are typically methods of signatures... *::Insert *::Remove *::DeleteAndDestroy *::Replace c) callcatcher ignores virtuals. But implementations of "pure virtuals" are not actually virtual methods. If something is declared pure virtual and provides an impl and that base-class impl is not explicitly called anywhere, then that impl can go away. d) gcc will only emit code for inlines if those inlines are used, so sometimes something is listed correctly as unused but some inline code takes a pointer or reference to something which cannot be instantiated so removal of some method/class fails at build time because gcc never emits any code for the unused inline but trips over it at compile time after an attempt at removal. i.e. generally the inline method can go as well because nothing calls it either, a double win. e) if a constructor is listed as unused, and it's the *only* ctor in the class, then no object of that class can be constructed, so the whole thing is unused, which can lead to a whole cascade of tricky but logical fallout. f) if a destructor is listed as unused, and a constructor isn't, then there's a leak somewhere, and the destructor most likely *should* be called. g) there's more actually unused code then what's listed. The idea is that what's listed is definitely unused under the generation configuration, not that it's a list of all unused code. If the count of unused easy hits 0 then we can have a look at the non-easy and if that hits 0, then strip out code from the "release" binaries which only makes sense in debug/dbgutil configurations, and then tackle unused virtual method slots :-) Symbols that are known to be false alarms are listed in: unusedcode.exclude [1] http://www.skynet.ie/~caolan/Packages/callcatcher.html [2] https://bugs.libreoffice.org/show_bug.cgi?id=38832 abora/co-24.04'>distro/collabora/co-24.04 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/external/cairo/cairo
AgeCommit message (Collapse)Author
2025-01-29Revert "remove unnecessary cairo soname patch"Stephan Bergmann
This reverts commit 3500c44bccafd442e50da604287342708506bb5c. Reason for revert: At least for Linux --without-system-cairo builds, this causes workdir/UnpackedTarball/cairo/src/.libs/libcairo.so (which is the lib that other libs like Library_drawinglayer and Library_vcl will link against) to have an SONAME of libcairo.so.2 (instead of libcairo-lo.so.2), so at runtime libs like instdir/program/libdrawinglayerlo.so and instdir/program/libvcllo.so will have a NEEDED of libcairo.so.2 (instead of libcairo-lo.so.2), so will pick up whatever system libcairo.so.2 (/usr/lib64/libcairo.so.2 from cairo-1.18.2-2.fc41.x86_64, in my case) instead of instdir/program/libcairo-lo.so.2, which caused e.g. CppunitTest_vcl_bitmap_render_test CPPUNIT_TEST_NAME=BitmapRenderTest::testTdf113918 to happen to fail for me with > [_RUN_____] BitmapRenderTest::testTdf113918 > warn:vcl.gdi:2234659:2234659:vcl/headless/CairoCommon.cxx:1619: unsupported SvpSalGraphics::drawAlphaBitmap case > vcl/qa/cppunit/bitmaprender/BitmapRenderTest.cxx:100:BitmapRenderTest::testTdf113918 > equality assertion failed > - Expected: rgba[ffffffff] > - Actual : rgba[008000ff] Change-Id: I9a2a64197185b7c057352c3fb7f3e3f6dbcf70db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180884 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2025-01-28remove unnecessary cairo soname patchNoel Grandin
This was introduced by commit 2def5485aa57d7c407a84ecc73b22083579e9a98 Author: Tor Lillqvist <tml@collabora.com> Date: Tue Sep 20 16:07:14 2022 +0300 Enable opening of downloaded fonts only in ForKit in Online but we don't need to this, since we rename the .so file when we copy it in external/cairo/ExternalPackage_cairo.mk This change makes a later patch less noisy/ Change-Id: I06f78d7ff068df14e95542391e20b669487ebb5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180794 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-08-27MSAN: Use-of-uninitialized-valueCaolán McNamara
==10765==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5a74216f620b in _cairo_path_fixed_fill_rectilinear_tessellate_to_boxes workdir/UnpackedTarball/cairo/src/cairo-path-fill.c:288:5 #1 0x5a74216f620b in _cairo_path_fixed_fill_rectilinear_to_boxes workdir/UnpackedTarball/cairo/src/cairo-path-fill.c:345:12 #2 0x5a7421735497 in _cairo_spans_compositor_fill workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:1121:11 num_limits is 0 here so this is apparently cosmetic Change-Id: Ib07259ce653414c9381c800355a648ab025d1919 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172457 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-07cool#7015 fix rgba emojisCaolán McNamara
We initially added this for android so we could match the OpenGL GL_RGBA layout available there. Later we made it available for all platforms via --enable-cairo-rgba which is useful for the kit case. But along the line color emoji support was added to cairo which wasn't present at the time of the original patch, so now capture those uses as well. https: //github.com/CollaboraOnline/online/issues/7015 Change-Id: I6039607a46a58a7e9cbf5c052e6fb34234fd19b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167225 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-06cairo RGBA needs to take account of custom RGB24_888 formatCaolán McNamara
Change-Id: I929d20f134c4fb7dedfd2c581263c303cae87eea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154080 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-05-17ofz#57493 reduce num_edges required to triggerCaolán McNamara
Change-Id: Idb6127d8943dbf62d8cacb7f2f5382a1e8619aae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151869 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-05-11ofz#57493 Timeout in _cairo_bo_event_queue_sort with > 200000 edgesCaolán McNamara
Change-Id: Id925da604647973977c25bbbfa57b1a69382e063 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151665 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-02-09Enable opening of downloaded fonts only in ForKit in OnlineTor Lillqvist
We want that only the ForKit process needs to have access to new font files added to a Collabora Online instance dynamically by downloading from a server. There are however many locations in the Kit process, in core and in external libraries like harfbuzz, where the code wants to open a font file. Handle this so that the ForKit process opens such a downloaded font file and doesn't close it. The file descriptor is thus inherited by Kit processes. The font file pathname passed on to other code is a fake on in the format "/:FD:/%d" where the %d is the file descriptor of the opened font file. Add checks in all places where font files are opened, look for this special pathname format, and modify the code to just dup() the already open file descriptor in that case. All this is relevant for Linux only, as Collabora Online runs on Linux. Do the above for harfbuzz, cairo, fontconfig, and freetype. In addition make sure that these libraries (except harfbuzz which needs to be a static library and freetype) when bundled, on Linux, are built as shared libraries, and won't be confused with the corresponding system libraries by making sure their sonames are different. Change-Id: Ib059cb27e1637d07bb709249abd0d984f948caa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140714 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146341 Tested-by: Jenkins
2022-09-02external/cairo: Remove dead code from cairo.RGB24_888.patchStephan Bergmann
...now that ab157ab93e0c5a62927947a8d2b0c1c277e526ac "move part of sanitizer patch to the patch that introduced the problem" unilaterally folded in here the content of f5e1314ffa564077c27fb9c954c792b498bcae12 "external/cairo: Fix previous -fsanitize=alignment fix", about which that commit's message had stated: "The following line > pixel &= 0x00ffffff; /* ignore next pixel bits */ should no longer be necessary now, and it is probably better to directly fix the original code in external/cairo/cairo/cairo-1.10.2.patch, but I'll leave that for a potential follow-up fix, once the provenance and assumed quality of that original CAIRO_FORMAT_RGB24_888 code is clarified." (The provenance and quality of that code is still not clarified though, see the still unanswered question in the comment at <https://gerrit.libreoffice.org/c/core/+/116637/2#message-407ec72875fcb015a3024f9a7ebf8480513b1e5e> "external/cairo: Fix previous -fsanitize=alignment fix".) Change-Id: Ic729bff238a35fac69d048b7c3912dd706a5b601 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139211 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-31move part of sanitizer patch to the patch that introduced the problemCaolán McNamara
Change-Id: I3fdec4dd5ae93187aebb4a17f9fb01f0a536c9cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139094 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-31ofz#50805 crash seen in fuzzing libreoffice text renderingCaolán McNamara
Change-Id: I8af207ff21399f1bc3f36c01b7d2912692cbb06b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139093 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-27ofz: -Wp,-D_FORTIFY_SOURCE=2 in cairo a problem with msanCaolán McNamara
Change-Id: I5c7bc7b9a370ee3a5c7dd3f7a2c92c5f2b193d58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138920 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-04upgrade to cairo 1.17.6Caolán McNamara
Change-Id: Ibdf84df380c89d3a0713163920a576bf1c47873a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133825 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-30ofz#46165 ubsan Divide-by-zeroCaolán McNamara
Change-Id: I5c56eae4456a03550770035610745de3be074679 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132299 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-07ofz: Use-of-uninitialized valueCaolán McNamara
Change-Id: I67063e20f5fc3c3418ee3db5c7a1f3e4a4a7121c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131100 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-12-04Fix cairo function pointer usageJan-Marek Glogowski
WASM strictly checks function signatures, so forced wrong casting of function pointers compiles, but any call will generate a runtime error, even if the argument is actually ignored. So this adds a bunch of wrapper functions to pass instead. Change-Id: Id976ea3ca81a792c8af539884ef741f5d23fc2c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126317 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-09-02external/cairo: Avoid UBSan invalid-null-argumentStephan Bergmann
...as seen during CppunitTest_sw_uiwriter4: > [_RUN_____] SwUiWriterTest4::testEmojiAutoCorrect cairo-surface.c:2852:28: runtime error: null pointer passed as argument 2, which is declared to never be null > /usr/include/string.h:44:28: note: nonnull attribute specified here > #0 in _cairo_surface_show_text_glyphs at workdir/UnpackedTarball/cairo/src/cairo-surface.c:2852:9 (instdir/program/libcairo.so.2 +0x9ac09e) > #1 in _cairo_gstate_show_text_glyphs at workdir/UnpackedTarball/cairo/src/cairo-gstate.c:2077:15 (instdir/program/libcairo.so.2 +0x65a4af) > #2 in _cairo_default_context_glyphs at workdir/UnpackedTarball/cairo/src/cairo-default-context.c:1315:12 (instdir/program/libcairo.so.2 +0x62404f) > #3 in cairo_show_glyphs at workdir/UnpackedTarball/cairo/src/cairo.c:3629:14 (instdir/program/libcairo.so.2 +0xa6c77f) > #4 in CairoTextRender::DrawTextLayout(GenericSalLayout const&, SalGraphics const&) at vcl/unx/generic/gdi/cairotextrender.cxx:265:9 (instdir/program/libvcllo.so +0xae46aa3) Change-Id: Ifa22046bb35a872c4db38130a7ae4c9b758ccbc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121473 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-31upgrade internal cairo and pixman to 1.17.4 and 0.40.0Caolán McNamara
cairo.RGB24_888.patch is split out from the rest of the unrelated patchfile it was in, this was introduced originally as: commit 54596087e57ea533253e19eea594d9b6c06e8d26 Author: Ashod Nakashian <ashod.nakashian@collabora.co.uk> Date: Sat Dec 9 16:28:42 2017 -0500 vcl-svp: add 24-bit (3-byte) RGB surface support to Cairo drop parts of pixman-ubsan.patch that no longer apply, which maybe casts doubt over the parts that do apply if they are still necessary Change-Id: Id1e8f112b1121b892c97ea248b101f133f03ac48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121234 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-06-03external/cairo: Fix previous -fsanitize=alignment fixStephan Bergmann
13f6d80330208eeb45fe9a03bb462941fb4eda2a "external/cairo: Support building with ASan/UBSan" had added the src/cairo-image-source.c blob to external/cairo/cairo/san.patch.0 to fix > > cairo-image-source.c:512:10: runtime error: load of misaligned address 0x6180037aee6f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment > during UITest_writer_tests7 I had created that patch attempting to do a faithful emulation of the original code (which I had naively assumed to be correct, modulo the alignment issue), reading four consecutive bytes and interpreting them as an uint32_t in the system's byte order. I had not noticed back then that all that CAIRO_FORMAT_RGB24_888 was added by external/cairo/cairo/cairo-1.10.2.patch, introduced with 54596087e57ea533253e19eea594d9b6c06e8d26 "vcl-svp: add 24-bit (3-byte) RGB surface support to Cairo". Its > + * @CAIRO_FORMAT_RGB24_888: each pixel is a 24-bit quantity, > + * with Red, Green, Blue taking 8-bits each, in that order. (Since 1.1x) and > + * Need this until CAIRO_FORMAT_RGB24_888 is in some official release. > + * Otherwise we can't reliably check if this is available or we should > + * convert from 24-bit RGB to 32-bit RGB before passing to Cairo. comments make it sound as if this code might come from some official cairo upstream branch, but I cannot find anything at git.freedesktop.org/git/cairo. I have no idea about the provenance and quality of that code. However, I now (a) from the above comments naively assume that the intent of CAIRO_FORMAT_RGB24_888 is to store R, G, B in that order in three bytes with increasing addresses (i.e., independent of the system's byte order for larger- than-byte words); (b) thus consider the original src/cairo-image-source.c code in external/cairo/cairo/cairo-1.10.2.patch broken (as it attempts to read all three values in one read, in system byte order, which would fail for big endian); and (c) thus consider the faithful emulation code in external/cairo/cairo/san.patch.0 to be broken, too. Based on the above, I here fix at least the external/cairo/cairo/san.patch.0 code (which is applied unconditionally, even for non-ASan/UBSan builds, thus always overriding the original external/cairo/cairo/cairo-1.10.2.patch code). The following line > pixel &= 0x00ffffff; /* ignore next pixel bits */ should no longer be necessary now, and it is probably better to directly fix the original code in external/cairo/cairo/cairo-1.10.2.patch, but I'll leave that for a potential follow-up fix, once the provenance and assumed quality of that original CAIRO_FORMAT_RGB24_888 code is clarified. (I came across this code now with a --without-system-cairo ASan/UBSan Linux build, where JunitTest_toolkit_unoapi_1 failed with > ==1060406==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300146fb48 at pc 0x7fff9b45b338 bp 0x7ffffffef1d0 sp 0x7ffffffef1c8 > READ of size 1 at 0x60300146fb48 thread T0 > Detaching from process 1060652 > #0 in _pixel_to_solid at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:515:207 > #1 in _pixman_image_for_surface at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1309:22 > #2 in _pixman_image_for_pattern at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1574:9 > #3 in _cairo_image_source_create_for_pattern at workdir/UnpackedTarball/cairo/src/cairo-image-source.c:1619:2 > #4 in composite_aligned_boxes at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:678:8 > #5 in clip_and_composite_boxes at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:882:11 > #6 in _cairo_spans_compositor_mask at workdir/UnpackedTarball/cairo/src/cairo-spans-compositor.c:999:14 > #7 in _cairo_compositor_mask at workdir/UnpackedTarball/cairo/src/cairo-compositor.c:106:11 > #8 in _cairo_image_surface_mask at workdir/UnpackedTarball/cairo/src/cairo-image-surface.c:952:12 > #9 in _cairo_surface_mask at workdir/UnpackedTarball/cairo/src/cairo-surface.c:2247:14 > #10 in _cairo_gstate_mask at workdir/UnpackedTarball/cairo/src/cairo-gstate.c:1136:11 > #11 in _cairo_default_context_mask at workdir/UnpackedTarball/cairo/src/cairo-default-context.c:993:12 > #12 in cairo_mask at workdir/UnpackedTarball/cairo/src/cairo.c:2283:14 > #13 in SvpSalGraphics::drawAlphaBitmap(SalTwoRect const&, SalBitmap const&, SalBitmap const&) at vcl/headless/svpgdi.cxx:745:5 > #14 in SalGraphics::DrawAlphaBitmap(SalTwoRect const&, SalBitmap const&, SalBitmap const&, OutputDevice const&) at vcl/source/gdi/salgdilayout.cxx:832:16 > #15 in OutputDevice::DrawDeviceAlphaBitmap(Bitmap const&, AlphaMask const&, Point const&, Size const&, Point const&, Size const&) at vcl/source/outdev/bitmap.cxx:704:29 > #16 in OutputDevice::DrawDeviceBitmap(Point const&, Size const&, Point const&, Size const&, BitmapEx&) at vcl/source/outdev/bitmap.cxx:516:9 > #17 in OutputDevice::DrawBitmapEx(Point const&, Size const&, Point const&, Size const&, BitmapEx const&, MetaActionType) at vcl/source/outdev/bitmap.cxx:391:9 > #18 in OutputDevice::DrawBitmapEx(Point const&, Size const&, BitmapEx const&) at vcl/source/outdev/bitmap.cxx:292:9 > #19 in OutputDevice::DrawTransformedBitmapEx(basegfx::B2DHomMatrix const&, BitmapEx const&, double) at vcl/source/outdev/bitmap.cxx:1315:9 > #20 in drawinglayer::processor2d::VclProcessor2D::RenderBitmapPrimitive2D(drawinglayer::primitive2d::BitmapPrimitive2D const&) at drawinglayer/source/processor2d/vclprocessor2d.cxx:394:21 > #21 in drawinglayer::processor2d::VclPixelProcessor2D::processBitmapPrimitive2D(drawinglayer::primitive2d::BitmapPrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:524:5 > #22 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:252:13 > #23 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #24 in drawinglayer::processor2d::VclProcessor2D::RenderTransformPrimitive2D(drawinglayer::primitive2d::TransformPrimitive2D const&) at drawinglayer/source/processor2d/vclprocessor2d.cxx:912:5 > #25 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:317:13 > #26 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #27 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:46:13 > #28 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) at drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:434:13 > #29 in drawinglayer::processor2d::BaseProcessor2D::process(drawinglayer::primitive2d::Primitive2DContainer const&) at drawinglayer/source/processor2d/baseprocessor2d.cxx:69:25 > #30 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:279:31 > #31 in sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo&) at svx/source/sdr/contact/objectcontactofpageview.cxx:116:21 > #32 in SdrPageWindow::RedrawAll(sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/sdrpagewindow.cxx:353:28 > #33 in SdrPageView::CompleteRedraw(SdrPaintWindow&, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpagv.cxx:239:18 > #34 in SdrPaintView::DoCompleteRedraw(SdrPaintWindow&, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpntv.cxx:606:21 > #35 in SdrPaintView::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at svx/source/svdraw/svdpntv.cxx:519:5 > #36 in sd::View::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at sd/source/ui/view/sdview.cxx:475:17 > #37 in sd::DrawView::CompleteRedraw(OutputDevice*, vcl::Region const&, sdr::contact::ViewObjectContactRedirector*) at sd/source/ui/view/drawview.cxx:520:21 > #38 in sd::DrawViewShell::Paint(tools::Rectangle const&, sd::Window*) at sd/source/ui/view/drviews5.cxx:420:17 > #39 in sd::Window::Paint(OutputDevice&, tools::Rectangle const&) at sd/source/ui/view/sdwindow.cxx:212:22 > #40 in PaintHelper::DoPaint(vcl::Region const*) at vcl/source/window/paint.cxx:313:20 > #41 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:616:17 > #42 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #43 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #44 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #45 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #46 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #47 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #48 in PaintHelper::~PaintHelper() at vcl/source/window/paint.cxx:552:30 > #49 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) at vcl/source/window/paint.cxx:622:1 > #50 in vcl::Window::PaintImmediately() at vcl/source/window/paint.cxx:1325:24 > #51 in vcl::Window::PaintImmediately() at vcl/source/window/paint.cxx:1269:39 > #52 in SvImpLBox::MyUserEvent(void*) at vcl/source/treelist/svimpbox.cxx:3063:18 > #53 in SvImpLBox::LinkStubMyUserEvent(void*, void*) at vcl/source/treelist/svimpbox.cxx:3057:1 > #54 in Link<void*, void>::Call(void*) const at include/tools/link.hxx:111:45 > #55 in ImplHandleUserEvent(ImplSVEvent*) at vcl/source/window/winproc.cxx:1991:30 > #56 in ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) at vcl/source/window/winproc.cxx:2561:13 > #57 in SalFrame::CallCallback(SalEvent, void const*) const at vcl/inc/salframe.hxx:306:29 > #58 in SvpSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) at vcl/headless/svpinst.cxx:312:22 > #59 in non-virtual thunk to SvpSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) at vcl/headless/svpinst.cxx (instdir/program/libvcllo.so +0xae7a222) > #60 in SalUserEventList::DispatchUserEvents(bool)::$_0::operator()() const at vcl/source/app/salusereventlist.cxx:119:58 > #61 in SalUserEventList::DispatchUserEvents(bool) at vcl/source/app/salusereventlist.cxx:120:13 > #62 in SvpSalInstance::DoYield(bool, bool) at vcl/headless/svpinst.cxx:461:19 > #63 in ImplYield(bool, bool) at vcl/source/app/svapp.cxx:465:48 > #64 in Application::Yield() at vcl/source/app/svapp.cxx:532:5 > #65 in Application::Execute() at vcl/source/app/svapp.cxx:444:9 > #66 in desktop::Desktop::Main() at desktop/source/app/app.cxx:1587:13 > #67 in ImplSVMain() at vcl/source/app/svmain.cxx:198:35 > #68 in SVMain() at vcl/source/app/svmain.cxx:230:12 > #69 in soffice_main at desktop/source/app/sofficemain.cxx:98:12 > #70 in sal_main at desktop/source/app/main.c:49:15 > #71 in main at desktop/source/app/main.c:47:1 > #72 in __libc_start_main at /usr/src/debug/glibc-2.33-8.fc34.x86_64/csu/../csu/libc-start.c:332:16 > #73 in _start at <null> (instdir/program/soffice.bin +0x251acd) > > 0x60300146fb48 is located 0 bytes to the right of 24-byte region [0x60300146fb30,0x60300146fb48) > allocated by thread T0 here: > #0 in operator new[](unsigned long) at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:102:3 > #1 in ImplCreateDIB(Size const&, vcl::PixelFormat, BitmapPalette const&) at vcl/headless/svpbmp.cxx:126:24 > #2 in SvpSalBitmap::Create(Size const&, vcl::PixelFormat, BitmapPalette const&) at vcl/headless/svpbmp.cxx:156:13 > #3 in Bitmap::Bitmap(Size const&, vcl::PixelFormat, BitmapPalette const*) at vcl/source/bitmap/bitmap.cxx:135:15 > #4 in Bitmap::Crop(tools::Rectangle const&) at vcl/source/bitmap/bitmap.cxx:489:20 > #5 in BitmapEx::Crop(tools::Rectangle const&) at vcl/source/bitmap/BitmapEx.cxx:360:25 > #6 in drawinglayer::primitive2d::DiscreteShadow::getLeft() const at drawinglayer/source/primitive2d/discreteshadowprimitive2d.cxx:148:61 > #7 in drawinglayer::primitive2d::DiscreteShadowPrimitive2D::create2DDecomposition(drawinglayer::primitive2d::Primitive2DContainer&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/discreteshadowprimitive2d.cxx:251:72 > #8 in drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/baseprimitive2d.cxx:122:9 > #9 in drawinglayer::primitive2d::DiscreteMetricDependentPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/primitivetools2d.cxx:48:47 trying to read the fourth byte of a presumed uint32_t starting at offset 21 of a 24-byte buffer.) Change-Id: Ibe8bc39e3736c64ace61af2217100c9d8bb96d5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116637 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-29external/cairo: Fix mask usage in image-compositorStephan Bergmann
Change-Id: Id3d8e4715e295290e07146ef06898b313ead57a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108449 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-30external/cairo: Silence some more UBSan warningsStephan Bergmann
...seen when opening an Impress presentation on GNOME/X11: > cairo-xlib-source.c:570:26: runtime error: left shift of 191 by 24 places cannot be represented in type 'int' > cairo-xlib-render-compositor.c:1852:17: runtime error: left shift of negative value -186 > cairo-xlib-render-compositor.c:1853:17: runtime error: left shift of negative value -646 > cairo-xlib-surface-shm.c:1157:43: runtime error: member access within null pointer of type 'cairo_xlib_shm_surface_t' (aka 'struct _cairo_xlib_shm_surface') > cairo-fixed-private.h:252:8: runtime error: left shift of negative value -146048 Change-Id: I93a5706c2ec3f83bc56d75fc92817668eef57fdb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105074 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-20external/cairo: Support building with ASan/UBSanStephan Bergmann
A full `make check screenshot` required lots of little "harmless" fixes in pixman and cairo to address: > cairo-image-compositor.c:133:34: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' during CppunitTest_emfio_emf > pixman-fast-path.c:3089:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' during CppunitTest_emfio_emf > pixman-sse2.c:5019:17: runtime error: load of misaligned address 0x7f99303dbac5 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_emfio_emf > cairo-fixed-private.h:64:14: runtime error: left shift of negative value -8388608 during CppunitTest_emfio_wmf > pixman-sse2.c:6443:20: runtime error: left shift of 198 by 24 places cannot be represented in type 'int' during CppunitTest_filter_svg > pixman-sse2.c:5976:6: runtime error: load of misaligned address 0x629000163202 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_filter_svg > pixman-sse2.c:3259:10: runtime error: load of misaligned address 0x606000c85761 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_oox_vml > pixman-sse2.c:521:18: runtime error: load of misaligned address 0x607000ca9d41 for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment during CppunitTest_oox_vml > pixman-gradient-walker.c:196:14: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' during CppunitTest_sc_tiledrendering > pixman-combine32.c:786:1: runtime error: left shift of 255 by 24 places cannot be represented in type 'int32_t' (aka 'int') during CppunitTest_vcl_backend_test > pixman-fast-path.c:2761:29: runtime error: left shift of negative value -99 during CppunitTest_xmloff_draw > pixman-bits-image.c:243:31: runtime error: left shift of negative value -99 during CppunitTest_xmloff_draw > pixman-bits-image.c:244:31: runtime error: left shift of negative value -9 during CppunitTest_sd_tiledrendering > pixman-fast-path.c:2762:29: runtime error: left shift of negative value -84 during CppunitTest_sw_rtfexport2 > cairo-gstate.c:2300:14: runtime error: null pointer passed as argument 1, which is declared to never be null during CppunitTest_sw_ooxmlexport8 > pixman-access.c:389:2: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' during CppunitTest_sw_ooxmlexport15 > ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ff264ae275c at pc 0x7ff238941795 bp 0x7fff6bbadb10 sp 0x7fff6bbadb08 > READ of size 4 at 0x7ff264ae275c thread T0 > #0 in _add_clipped_edge at workdir/UnpackedTarball/cairo/src/cairo-polygon.c:351:24 (instdir/program/libcairo.so.2 +0x88c794) during CppunitTest_sw_odfexport > cairo-tor-scan-converter.c:1619:34: runtime error: left shift of negative value -39 during CppunitTest_sw_odfexport > ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fe6ca085750 at pc 0x000000325c3a bp 0x7fff899bedd0 sp 0x7fff899be580 > READ of size 16 at 0x7fe6ca085750 thread T0 > #0 in __asan_memcpy at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 (workdir/LinkTarget/Executable/cppunittester +0x325c39) during CppunitTest_sw_odfexport > pixman-sse2.c:3352:14: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int' during CppunitTest_sw_odfexport > cairo-gstate.c:2355:14: runtime error: null pointer passed as argument 1, which is declared to never be null during CppunitTest_basctl_dialogs_test > pixman-sse2.c:3537:10: runtime error: load of misaligned address 0x615000167682 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during CppunitTest_sc_screenshots > cairo-image-source.c:512:10: runtime error: load of misaligned address 0x6180037aee6f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment during UITest_writer_tests7 Change-Id: Icd2a211df4751d8dbfd5903bfba424b4c4672999 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104572 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-25Related: tdf#136980 cairo: avoid linking to freetype-2.8-only ...Miklos Vajna
... FT_Get_Var_Design_Coordinates This is meant to help producing binaries which run on Ubuntu 16.04. Change-Id: I7fc965c265d2ac97a6836df0829d3d4cd0cc9333 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103392 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-25tdf#136980 cairo: avoid linking to freetype-2.8 symbolsMiklos Vajna
This is meant to help producing binaries on CentOS 7 which run on Ubuntu 16.04, when using internal cairo. Change-Id: Ie4cd3fe707225a951ec8a5fb49a755064701dcfa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103378 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-09-05tdf#121983 cairo: fix RPATH to contain $ORIGIN, not libtool's nonsenseMichael Stahl
Also transmit $(verbose) to the build so it's debuggable. Change-Id: I8620fdcae2fcd34807b6b83b7c38aa5ca1ba2caa Reviewed-on: https://gerrit.libreoffice.org/78596 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>