[Libreoffice-bugs] [Bug 134754] Crash on macOS 10.13 opening local HSQLDB-based odb file in Base on LibreOffice 7 rc1

Sat Dec 5 15:56:55 UTC 2020

https://bugs.documentfoundation.org/show_bug.cgi?id=134754

Stephan Bergmann <sbergman at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #22 from Stephan Bergmann <sbergman at redhat.com> ---
(In reply to leoneo3000 from comment #14)
> I have bibisected this issue on MacOS 10.13.6 (High Sierra) using the
> AdoptOpenJDK 15. This is reported as the offending commit:
> 
> 6341a00ca2270062e834ac95a9f0613f2bc9168e is the first bad commit
> commit 6341a00ca2270062e834ac95a9f0613f2bc9168e
> Author: libreoffice <libreoffice at libreoffices-Mac-mini.local>
> Date:   Wed Jun 17 01:24:33 2020 +0200
> 
>     source sha:2c366aae9263dc4115b054fe74b90cabea61fa0b
> 
>     source sha:2c366aae9263dc4115b054fe74b90cabea61fa0b
> 
> :040000 040000 f4e33678d7824827d2d83eb14d15d244dacb955d
> 63fb87cdd42ce753dfc58eb884dfd6bd0317297a M	LibreOffice.app

This does look somewhat plausible. 
<https://git.libreoffice.org/core/+/2c366aae9263dc4115b054fe74b90cabea61fa0b%5E!>
"Use a less extreme entitlement for our run-time machine code generation" has
two parts:  One part is that it changed from
com.apple.security.cs.disable-executable-page-protection to
com.apple.security.cs.allow-jit, which caused bug 135479 "LO Complains about
missing JDK when accessing any Java functionality, despite recognizing JDK on
macOS under Preferences".  That part has meanwhile been reverted (see bug
135479 for details).

The other part is that it changed MACOSX to use

>     p = mmap(
>         nullptr, n, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANON | MAP_JIT, -1,
>         0);

This part fails to handle the case where mmap returns MAP_FAILED.  I cannot
reproduce the recipe from comment 0 on my macOS 10.15 machine, but if I change
the above code to always fail with MAP_FAILED,

> diff --git a/bridges/source/cpp_uno/shared/vtablefactory.cxx b/bridges/source/cpp_uno/shared/vtablefactory.cxx
> index 52309c6ec617..837a059f612e 100644
> --- a/bridges/source/cpp_uno/shared/vtablefactory.cxx
> +++ b/bridges/source/cpp_uno/shared/vtablefactory.cxx
> @@ -82,9 +82,9 @@ extern "C" void * allocExec(
>      void * p;
>  #if defined SAL_UNX
>  #if defined MACOSX
> -    p = mmap(
> +    p = MAP_FAILED/*mmap(
>          nullptr, n, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANON | MAP_JIT, -1,
> -        0);
> +        0)*/;
>  #else
>      p = mmap(
>          nullptr, n, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1,

I get the same effect as documented in the crash logs attached by the reporter:

> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7)
>   * frame #0: 0x000000010ee1903c libgcc3_uno.dylib`bridges::cpp_uno::shared::VtableFactory::initializeBlock(block=0xffffffffffffffff, slotCount=5, (null)=0, (null)=0x000000014305d5b0) + 12 at /Users/stephan/Software/lo2/core/bridges/source/cpp_uno/gcc3_macosx_x86-64/cpp2uno.cxx:460
>     frame #1: 0x000000010ee1f2af libgcc3_uno.dylib`bridges::cpp_uno::shared::VtableFactory::createVtables(this=0x000000010ee28410, blocks=0x00007ffeefbfe5d0, baseOffset=0x00007ffeefbfe5a0, type=0x000000014305d5b0, vtableNumber=0, mostDerived=0x000000014305d5b0, includePrimary=<unavailable>) const + 143 at /Users/stephan/Software/lo2/core/bridges/source/cpp_uno/shared/vtablefactory.cxx:341
>     frame #2: 0x000000010ee1ec56 libgcc3_uno.dylib`bridges::cpp_uno::shared::VtableFactory::getVtables(this=0x000000010ee28410, type=0x000000014305d5b0) + 198 at /Users/stephan/Software/lo2/core/bridges/source/cpp_uno/shared/vtablefactory.cxx:212

(Doing a minimal fix of setting p=nullptr upon MAP_FAILED, as has always been
done in the !MACOSX case, would not help much, though.  Instead of a SIGSEGV
crash, LO would crash due to an unhandled css.deployment.DeploymentException.)

It appears that in some scenarios (maybe always on macOS 10.13?, maybe only in
the reporter's environment?), the modified mmap call (passing PROT_EXEC and
MAP_JIT) will fail with MAP_FAILED.

One fix could be to also revert this second part of
2c366aae9263dc4115b054fe74b90cabea61fa0b.  My assumption is that without the
other, already reverted part, it does not serve much of a purpose anyway?  Tor,
what would you say?

Another fix could be to keep the extended (PROT_EXEC, MAP_JIT) mmap call, but
if it fails (with a specific errno value), retry with the old (no PROT_EXEC,
MAP_JIT) mmap call.  For that, it would be interesting to learn what errno
value this fails with for the reporter:

leoneo3000, can you please run the below small maptest.c program from a
Terminal window and report its output?  You can either compile it yourself (`cc
maptest.c -o maptest`) or use the attached maptest executable (if you download
it to your Downloads directory, then in the Terminal window type
`~/Downloads/maptest`, without the surrounding `...`).

> #include <stddef.h>
> #include <stdio.h>
> #include <sys/mman.h>
> int main() {
>   if (mmap(
>         NULL, 100, PROT_READ | PROT_WRITE | PROT_EXEC,
>         MAP_PRIVATE | MAP_ANON | MAP_JIT, -1, 0)
>       == MAP_FAILED)
>   {
>     perror("failure");
>   } else {
>     printf("success\n");
>   }
> }

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201205/6d9f2f02/attachment-0001.htm>