PDFium, beware

classic Classic list List threaded Threaded
5 messages Options
sberg sberg
Reply | Threaded
Open this post in threaded view
|

PDFium, beware

Recent master --enable-pdfium has at
workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/page_allocator.h:31

> // All Blink-supported systems have 4096 sized system pages and can handle
> // permissions and commit / decommit at this granularity.
> static const size_t kSystemPageSize = 4096;

and upstream master at
<https://pdfium.googlesource.com/pdfium/+/026717cb667cf0c7215cf55daf794d69752fc900/third_party/base/allocator/partition_allocator/page_allocator.h#33>
isn't much better with

> // All Blink-supported systems have 4096 sized system pages and can handle
> // permissions and commit / decommit at this granularity.
> // Loongson have 16384 sized system pages.
> #if defined(_MIPS_ARCH_LOONGSON)
> static const size_t kSystemPageSize = 16384;
> #else
> static const size_t kSystemPageSize = 4096;
> #endif

This causes failure e.g. on Linux aarch64 machines with 64K page size,
see
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=ffc134445ef7e935d18d816626f64e65b4cdbca6>
"--disable-pdfium for Linux aarch64 Flatpak build", but other platforms
may be affected, too.  (On RH internal tech-list  I got comments "NB,
even before aarch64 came along, that code is broken because ppc64 uses a
64kb page size by default." and "And alpha and sparc/sparc64 use 8K
pages, for example.  Not to mention that a lot of other architectures
have configurable page size.")

So think twice before you live with (enabled-by-default) --enable-pdfium.

Or start searching for an alternative?
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Norbert Thiebaud Norbert Thiebaud
Reply | Threaded
Open this post in threaded view
|

Re: PDFium, beware

On Fri, Feb 9, 2018 at 6:33 PM, Stephan Bergmann <[hidden email]> wrote:
> Recent master --enable-pdfium has at
> workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/page_allocator.h:31
>
>> // All Blink-supported systems have 4096 sized system pages and can handle
>> // permissions and commit / decommit at this granularity.
>> static const size_t kSystemPageSize = 4096;

and sysconf(_SC_PAGE_SIZE) is not working ?
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: PDFium, beware

On 09.02.2018 19:53, Norbert Thiebaud wrote:
> On Fri, Feb 9, 2018 at 6:33 PM, Stephan Bergmann <[hidden email]> wrote:
>> Recent master --enable-pdfium has at
>> workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/page_allocator.h:31
>>
>>> // All Blink-supported systems have 4096 sized system pages and can handle
>>> // permissions and commit / decommit at this granularity.
>>> static const size_t kSystemPageSize = 4096;
>
> and sysconf(_SC_PAGE_SIZE) is not working ?

At least not easily, no.  There's various static_asserts in
workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/partition_alloc.cpp
involving kSystemPageSize that would fail if kSystemPageSize was 65536
instead of 4096 (and those uses of static_assert would of course need to
be done differently if kSystemPageSize wasn't a constant expression).
That smells like the code as written indeed depends on specific
qualities of kSystemPageSize.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-4 Miklos Vajna-4
Reply | Threaded
Open this post in threaded view
|

Re: PDFium, beware

Hi,

Do I understand correctly the source of the problem is their custom
allocator? If so, I guess talking to the pdfium devs and ask them to
provide a way to avoid their custom allocator (a compile-time option)
would help our situation, or did I miss something? (I can at least try
to talk to them, they merged various "don't use bundled XYZ" patches
before from me.)

Before we throw something out of the window, just for one detail. :-)

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (188 bytes) Download Attachment
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: PDFium, beware

On 12.02.2018 09:29, Miklos Vajna wrote:
> Do I understand correctly the source of the problem is their custom
> allocator?

Yes.  See below for the backtrace of failing CppunitTest_svtools_graphic
on Linux aarch64 with 64K page size.

> If so, I guess talking to the pdfium devs and ask them to
> provide a way to avoid their custom allocator (a compile-time option)
> would help our situation, or did I miss something? (I can at least try
> to talk to them, they merged various "don't use bundled XYZ" patches
> before from me.)

If that could indeed be disabled, that should solve it.  So if you want
to ask upstream, please go ahead.


> #1  0x0000ffff7fd61da4 in abort () at /lib/libc.so.6
> #2  0x0000ffff7b9341e4 in pdfium::base::SetSystemPagesInaccessible(void*, unsigned long) (address=address@entry=0x1029e02000, length=length@entry=8192) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/page_allocator.cpp:198
> #3  0x0000ffff7b93518c in pdfium::base::PartitionAllocSlowPath(pdfium::base::PartitionRootBase*, int, unsigned long, pdfium::base::PartitionBucket*) (num_partition_pages=<optimized out>, flags=0, root=0xffff7fe82c80) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/partition_alloc.cpp:403
> #4  0x0000ffff7b93518c in pdfium::base::PartitionAllocSlowPath(pdfium::base::PartitionRootBase*, int, unsigned long, pdfium::base::PartitionBucket*) (root=0xffff7fe82c80, root@entry=0xffff7bb4c8f8 <gStringPartitionAllocator>, flags=flags@entry=0, size=size@entry=80, bucket=0xffff7fe749d0, bucket@entry=0xffff7bb4e180 <gStringPartitionAllocator+6280>) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/partition_alloc.cpp:816
> #5  0x0000ffff7b8e28e8 in fxcrt::StringDataTemplate<char>::Create(unsigned long) (bucket=0xffff7bb4e180 <gStringPartitionAllocator+6280>, size=80, flags=0, root=<optimized out>) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/partition_alloc.h:675
> #6  0x0000ffff7b8e28e8 in fxcrt::StringDataTemplate<char>::Create(unsigned long) (type_name=0xffff7ba49d40 "StringDataTemplate", size=<optimized out>, flags=0, root=<optimized out>) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/partition_alloc.h:798
> #7  0x0000ffff7b8e28e8 in fxcrt::StringDataTemplate<char>::Create(unsigned long) (type_name=0xffff7ba49d40 "StringDataTemplate", size=<optimized out>, root=<optimized out>) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/third_party/base/allocator/partition_allocator/partition_alloc.h:808
> #8  0x0000ffff7b8e28e8 in fxcrt::StringDataTemplate<char>::Create(unsigned long) (nLen=nLen@entry=16) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/core/fxcrt/string_data_template.h:39
> #9  0x0000ffff7b8e2a18 in fxcrt::StringDataTemplate<char>::Create(char const*, unsigned long) (pStr=0xffff7bac56b5 "/usr/share/fonts", nLen=16) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/core/fxcrt/string_data_template.h:51
> #10 0x0000ffff7b8e01cc in fxcrt::ByteString::ByteString(char const*, unsigned long) (this=0xffffdef31c50, pStr=<optimized out>, nLen=<optimized out>) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/core/fxcrt/bytestring.cpp:96
> #11 0x0000ffff7b90d394 in IFX_SystemFontInfo::CreateDefault(char const**) (pUserPaths=0x0) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/core/fxge/fx_ge_linux.cpp:151
> #12 0x0000ffff7b90d4b4 in CFX_GEModule::InitPlatform() (this=<optimized out>) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/core/fxge/fx_ge_linux.cpp:161
> #13 0x0000ffff7b907630 in CFX_GEModule::Init(char const**) (this=<optimized out>, userFontPaths=<optimized out>) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/core/fxge/cfx_gemodule.cpp:46
> #14 0x0000ffff7b8088a4 in FPDF_InitLibraryWithConfig(FPDF_LIBRARY_CONFIG const*) (cfg=0xffffdef31d80) at /run/build/libreoffice/workdir/UnpackedTarball/pdfium/fpdfsdk/fpdfview.cpp:463
> #15 0x0000ffff7caadb50 in vcl::ImportPDF(SvStream&, Bitmap&, com::sun::star::uno::Sequence<signed char>&, unsigned long, unsigned long) () at /run/build/libreoffice/instdir/program/libvcllo.so
[...]
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice