Download it now!
Bug 134754 - Crash on macOS 10.13 opening local HSQLDB-based odb file in Base on LibreOffice 7 rc1
Summary: Crash on macOS 10.13 opening local HSQLDB-based odb file in Base on LibreOffi...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.0.0.1 rc
Hardware: All Mac OS X (All)
: high critical
Assignee: Stephan Bergmann
URL:
Whiteboard: target:7.2.0 target:7.1.0.0.beta2 tar...
Keywords: bibisected, bisected, regression
: 135975 137076 138670 (view as bug list)
Depends on:
Blocks: Crash Database-HSQLDB
  Show dependency treegraph
 
Reported: 2020-07-12 15:50 UTC by leoneo3000
Modified: 2020-12-20 22:07 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Apple crash log (96.51 KB, text/rtf)
2020-07-12 16:21 UTC, leoneo3000
Details
Apple crash log with Oracle JDK 14.0.2 (102.36 KB, text/plain)
2020-07-17 09:35 UTC, leoneo3000
Details
Apple crash log in 7.1a with OpenJDK 15 (107.21 KB, text/plain)
2020-11-05 20:28 UTC, leoneo3000
Details
test executable (48.35 KB, application/octet-stream)
2020-12-05 15:56 UTC, Stephan Bergmann
Details
Crash log when creating net HSQLDB in 7.2.0.0.alpha0 (124.00 KB, text/plain)
2020-12-07 16:16 UTC, leoneo3000
Details
soffice output in 7.2.0.0.alpha0 as per request (3.08 KB, text/plain)
2020-12-07 16:22 UTC, leoneo3000
Details
soffice output in 7.2.0.0.alpha0, take two (4.62 KB, text/plain)
2020-12-07 18:01 UTC, leoneo3000
Details
screenshot LibreOffice java (79.33 KB, image/png)
2020-12-08 14:22 UTC, HTK300
Details
apple crash dump #2 (114.70 KB, text/plain)
2020-12-08 17:59 UTC, HTK300
Details
screenshot crashed LO (28.46 KB, image/png)
2020-12-08 18:07 UTC, HTK300
Details
select Tables (48.52 KB, image/png)
2020-12-08 18:08 UTC, HTK300
Details
JRE settings within LibreOffice preferences >advanced (31.50 KB, image/png)
2020-12-08 18:10 UTC, HTK300
Details

Note You need to log in before you can comment on or make changes to this bug.
Description leoneo3000 2020-07-12 15:50:14 UTC
Description:
Opening a file with an embedded HSQLDB crashes as soon as I want to see Tables or Queries (but not Reports or Forms)

Working with files with an embedded Firebird DB works fine.

Steps to Reproduce:
1. Create a very basic odb file using an embedded HSQLDB (using either LO 6.4.5 or LO7rc1). I am using a file with no tables, queries, forms or reports yet.
2. Open the file and switch to either Table view or Query view
3. Witness a crash producing an Apple crash log

Actual Results:
Crash producing an Apple crash log

Expected Results:
The ability to create a first table in the DB.


Reproducible: Always


User Profile Reset: No



Additional Info:
As I believe the HSQLDB relies on Java whereas the Firebird DB does not, could the problem lie in Java? I am using the AdoptOpenJDK 1.8.0_242 JRE (and it's selected in LO preferences).

Version: 7.0.0.1
Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd
CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded
Comment 1 leoneo3000 2020-07-12 16:21:29 UTC
Created attachment 162930 [details]
Apple crash log

As you can see, I have renamed LibreOffice.app to LibreOffice7rc1.app so I can run the RC and LO 6.4.5 alongside each other. I doubt that will be the cause of the crash.
Comment 2 Alex Thurgood 2020-07-13 08:09:48 UTC
(In reply to leoneo3000 from comment #0)




> Additional Info:
> As I believe the HSQLDB relies on Java whereas the Firebird DB does not,
> could the problem lie in Java? I am using the AdoptOpenJDK 1.8.0_242 JRE
> (and it's selected in LO preferences).
> 


I'm somewhat surprised that the 1.8.0 JDK from AdoptOpenJDK is still recognized.

No repro for me with
Version: 7.0.0.1
Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd
CPU threads: 8; OS: Mac OS X 10.15.5; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

Oracle JDK 12.0.2
Comment 3 leoneo3000 2020-07-13 11:38:39 UTC
Good spot. With both AdoptJDK 11.0.7 (the current LTS version) and AdoptJDK 14.0.1 (the latest version) I still have the same crashes, though.
Comment 4 Alex Thurgood 2020-07-13 16:18:54 UTC
(In reply to leoneo3000 from comment #3)
> Good spot. With both AdoptJDK 11.0.7 (the current LTS version) and AdoptJDK
> 14.0.1 (the latest version) I still have the same crashes, though.

Usually, when something like this happens, it is generally either because :

- the vendor name isn't recognized correctly by LO ; or

- the JDK is trying to do something with the class libraries the UNO Affine bridge doesn't know how to handle.

Not much I can say there other than try with OracleOpenJDK or just OracleJDK and see if the problem is reproducible. If it isn't, it would be an indication that the AdoptOpenJDK is the issue (somewhere in my brain is a recollection that some already reported issues with AdoptOpenJDK).
Comment 5 leoneo3000 2020-07-17 09:35:45 UTC
Created attachment 163159 [details]
Apple crash log with Oracle JDK 14.0.2

I have just installed Oracle JDK 14.0.2 (not ideal as with its 323MB it's half the size of the whole LibreOffice suite) but the crashes remain.

The issue seems the same, "Crashed Thread: 10  UNO AffineBridge InnerThread"

Are there other places in LO7 that still depend on Java so I can see if it's an issue specific to Base or more broader?

You can't reproduce this on a Mac but you are running a newer version of the OS (10.15.5 vs. my 10.13.6). Unfortunately I can't update further on this machine as the hardware is too old. Is there a way to find out if it's an issue specific to the OS version?
Comment 6 Alex Thurgood 2020-07-17 13:21:44 UTC
(In reply to leoneo3000 from comment #5)

> 
> Are there other places in LO7 that still depend on Java so I can see if it's
> an issue specific to Base or more broader?

You could try installing an extension that relies on Java to see whether you can invoke the same crash error message:

https://extensions.libreoffice.org/?q=java&action_doExtensionSearch=Search




> machine as the hardware is too old. Is there a way to find out if it's an
> issue specific to the OS version?

Not that I know of, other than trawling the internet for similar crash reports.
Comment 7 jphilly2 2020-07-20 09:52:18 UTC
Comment on attachment 162930 [details]
Apple crash log

I have MAC Catalina 10.15.6 and Libre Office crashes every time I try to open it or open a L.O. document. Version 6.4.4.2. I am a user, not a programmer.  Been using L.O.for many years.
Comment 8 Alex Thurgood 2020-07-21 10:41:37 UTC
(In reply to jphilly2 from comment #7)
> Comment on attachment 162930 [details]
> Apple crash log
> 
> I have MAC Catalina 10.15.6 and Libre Office crashes every time I try to
> open it or open a L.O. document. Version 6.4.4.2. I am a user, not a
> programmer.  Been using L.O.for many years.


I don't see the relationship here to the initial bug report unfortunately.
Comment 9 Alex Thurgood 2020-08-26 07:37:37 UTC
A similar issue has been reported by another user on macOS 10.13 in bug 135975
Comment 10 Alex Thurgood 2020-09-16 05:15:37 UTC
*** Bug 135975 has been marked as a duplicate of this bug. ***
Comment 11 Alex Thurgood 2020-09-16 05:16:38 UTC
Given duplicate report on same macOS version, setting to new.
Comment 12 Alex Thurgood 2020-09-17 08:26:17 UTC
I see the bibisect request, but who is going to bibisect on macOS 10.13 ?
Comment 13 leoneo3000 2020-09-18 11:52:02 UTC
I have never done bibisecting before but willing to give it a try some time in the next two weeks. Are there any pointers as to which build I’d need to start with to narrow the range? Perhaps someone knows that substantial work was done on some of the code linking to Java in build such and such so that’s where I should focus on.

FYI, this issue is still there with LibreOffice 7.0.1.2 and AdoptOpenJDK 15 on macOS 10.13.6.
Comment 14 leoneo3000 2020-09-26 11:37:29 UTC
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@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
Comment 15 Alex Thurgood 2020-09-28 07:41:55 UTC
*** Bug 137076 has been marked as a duplicate of this bug. ***
Comment 16 Alex Thurgood 2020-09-28 07:47:18 UTC
Thanks !

This might actually be fixed in an upcoming release of 7.1, as at least part of the above commit has been reverted in a change to try and fix bug 135479.
Comment 17 Buovjaga 2020-11-05 11:03:15 UTC
(In reply to Alex Thurgood from comment #16)
> Thanks !
> 
> This might actually be fixed in an upcoming release of 7.1, as at least part
> of the above commit has been reverted in a change to try and fix bug 135479.

leoneo3000: please test with 7.1 https://dev-builds.libreoffice.org/daily/master/current.html
Comment 18 leoneo3000 2020-11-05 20:28:44 UTC
Created attachment 167045 [details]
Apple crash log in 7.1a with OpenJDK 15

Unfortunately it appears that this issue is not solved in 7.1a build 7dc234fa57ca409d0db131c93abea738014b5e1f.
Comment 19 Julien Nabet 2020-12-05 11:13:05 UTC
*** Bug 138670 has been marked as a duplicate of this bug. ***
Comment 20 Julien Nabet 2020-12-05 11:27:32 UTC
Let's put this one to almost max priority since it only concerns Mac but:
- it's a crash
- it's easily reproduceable
- a fundamental case (not a corner case)
- a regression

So for Mac users, I think it's a real blocker (at least for those who use Base but if related to Java it may also crash at some other locations).

Stephan/Tor: thought you might be interested in this one since it seems you're the only LO dev experts which use a Mac.

Also, https://bugs.documentfoundation.org/show_bug.cgi?id=134754#c14 indicates:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=2c366aae9263dc4115b054fe74b90cabea61fa0b
"
Use a less extreme entitlement for our run-time machine code generation
See https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-executable-page-protection
and https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit
"

I never did a bibisect (don't want to download Go of data and don't have the patience) and it was the first one for the reporter so it may be the wrong commit.
Of course, this commit may be not the root cause but the element which revealed a bug.

I also know that there are more "flavors" of Java now (and some may have weird behaviour or may be a bit buggy) + the fact it seems not easy to make LO detect Java install on Mac, this brings an extra difficulty.
Comment 21 Stephan Bergmann 2020-12-05 15:56:15 UTC
Created attachment 167849 [details]
test executable
Comment 22 Stephan Bergmann 2020-12-05 15:56:55 UTC
(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@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");
>   }
> }
Comment 23 Stephan Bergmann 2020-12-06 13:19:10 UTC
(In reply to Stephan Bergmann from comment #22)
> 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 `...`).

`chmod +x ~/Downloads/maptest && ~/Downloads/maptest` would be the right incantation.  (Though when I tried that now on an old Mac OS X 10.7.5 machine: the prebuilt maptest crashed with SIGSEGV in __dyld__dyld_start, presumably because what I naively built on the macOS 10.15 machine isn't able to run on old versions; while a built-from-scratch maptest prints "success", so that test may not be that useful anyway, after all.)
Comment 24 Commit Notification 2020-12-06 17:38:16 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/cca1240fe5884f184af489f5326e96892d1ae975

Related tdf#134754: Detect failed mmap on macOS

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 Stephan Bergmann 2020-12-07 07:33:02 UTC
leoneo3000, so here is a better thing you can please do to provide the relevant information:  Download and install the latest daily build (<https://wiki.documentfoundation.org/QA/Testing_Daily_Builds>) that includes the commit from comment 23, e.g., <https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@tb81-TDF/2020-12-07_04.17.23/LibreOfficeDev_7.2.0.0.alpha0_MacOS_x86-64.dmg>.  Start and quit ("LibreOfficeDev - Quit LibreOfficeDev") the installed LibreOffideDev once to make sure it gets the proper permissions in your environment.  Then from a Terminal window type `/Applications/LibreOfficeDev.app/Contents/MacOS/soffice` (without the surrounding `...`, and assuming you installed the LibreOfficeDev to the default Applications folder).  Then let LibreOffice crash; it should print lines in the Terminal window which you please all copy here.
Comment 26 leoneo3000 2020-12-07 16:16:50 UTC
Created attachment 167905 [details]
Crash log when creating net HSQLDB in 7.2.0.0.alpha0

Creating a new HSQLDB in that LO 7.2.0.0.alpha0 produces this crash.

Considering that duplicate (bug 138670) and myself use macOS 10.13, and other versions of the OS don't seem to replicate, it's probably specific to macOS 10.13.
Comment 27 leoneo3000 2020-12-07 16:22:41 UTC
Created attachment 167906 [details]
soffice output in 7.2.0.0.alpha0 as per request

Stephan Bergmann, I believe this is what you requested. I changed some paths and filenames for privacy in the output but I doubt that will hinder you.

Both this output and the preceding crash log 167905 were against the AdoptOpenJDK 15.
Comment 28 Stephan Bergmann 2020-12-07 17:04:14 UTC
(In reply to leoneo3000 from comment #27)
> Created attachment 167906 [details]
> soffice output in 7.2.0.0.alpha0 as per request
> 
> Stephan Bergmann, I believe this is what you requested. I changed some paths
> and filenames for privacy in the output but I doubt that will hinder you.
> 
> Both this output and the preceding crash log 167905 were against the
> AdoptOpenJDK 15.

Is this output from a run of LO that you caused to crash as per comment 0?
Comment 29 leoneo3000 2020-12-07 18:01:38 UTC
Created attachment 167909 [details]
soffice output in 7.2.0.0.alpha0, take two

Is this better? It seems to search for a couple of files that are in Recent Documents or the opening pane and it can't find and report that.

As soon as I want to do anything with an ODB file that requires Java (Tables or Queries) LO crashes. This is all the output to the command line.
Comment 30 Stephan Bergmann 2020-12-07 18:13:22 UTC
(In reply to leoneo3000 from comment #29)
> Created attachment 167909 [details]
> soffice output in 7.2.0.0.alpha0, take two
> 
> Is this better? It seems to search for a couple of files that are in Recent
> Documents or the opening pane and it can't find and report that.
> 
> As soon as I want to do anything with an ODB file that requires Java (Tables
> or Queries) LO crashes. This is all the output to the command line.

Yes, thanks, this shows the relevant line

> warn:bridges.osx:17098:313708:bridges/source/cpp_uno/shared/vtablefactory.cxx:90: mmap failed with 22, Invalid argument

(while the output preceding that is harmless and expected).
Comment 31 Commit Notification 2020-12-08 09:43:10 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6cab5c9170dc167838f1aebafc47153cd84713b4

tdf#134754: Gracefully handle EINVAL from mmap MAP_JIT on old macOS

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 32 Stephan Bergmann 2020-12-08 09:58:04 UTC
(In reply to Commit Notification from comment #31)
> Stephan Bergmann committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> 6cab5c9170dc167838f1aebafc47153cd84713b4
> 
> tdf#134754: Gracefully handle EINVAL from mmap MAP_JIT on old macOS
> 
> It will be available in 7.2.0.

backports:
* libreoffice-7-1 <https://gerrit.libreoffice.org/c/core/+/107395>
* libreoffice-7-0 <https://gerrit.libreoffice.org/c/core/+/107377>
* libreoffice-7-0-4 <https://gerrit.libreoffice.org/c/core/+/107378>
Comment 33 Stephan Bergmann 2020-12-08 12:39:53 UTC
(In reply to Stephan Bergmann from comment #22)
[...]
> 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?

(The above has been made moot now now by <https://gerrit.libreoffice.org/c/core/+/107410> "Explicitly require com.apple.security.cs.allow-jit", considering MAP_JIT and com.apple.security.cs.allow-jit the way forward, and com.apple.security.cs.disable-executable-page-protection a stopgap fix for the time being.)

> 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:

(The above is the fix that has been implemented, see comment 31.)
Comment 34 Commit Notification 2020-12-08 13:50:36 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/3d282909e8370e7ae43d018a5068a8cae40b1d05

tdf#134754: Gracefully handle EINVAL from mmap MAP_JIT on old macOS

It will be available in 7.1.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 35 HTK300 2020-12-08 14:21:48 UTC
thank you for your hard work, appreciate it so much. I have filed this bug and have been following conversations, yet I am not a developer.

I will test this on my MacBook Pro manufactured late 2011 
using macOS 10.13 High Sierra which ist highest possible, 
it runs on 12 GB of RAM running under Java jdk 13.0.1 see attached screen shot.

I also have 3 more individual laptops running Windows 7, 8, 10 each alone. 
If you want me to do user test there as well, let me know.


Harry
P.S. I have an old certificate from ISTQB as CERTIFIED TESTER foundation level yet little experience.
Comment 36 HTK300 2020-12-08 14:22:43 UTC
Created attachment 167975 [details]
screenshot LibreOffice java

fyi
Comment 37 Stephan Bergmann 2020-12-08 15:18:35 UTC
(In reply to HTK300 from comment #35)
> I will test this on my MacBook Pro manufactured late 2011 
> using macOS 10.13 High Sierra which ist highest possible, 
> it runs on 12 GB of RAM running under Java jdk 13.0.1 see attached screen
> shot.

Great.  You can set this bug to VERIFIED when you see it actually fixed (or report back if not, of course...)

> I also have 3 more individual laptops running Windows 7, 8, 10 each alone. 
> If you want me to do user test there as well, let me know.

That wouldn't be necessary (both the issue and the fix are very much Mac-specific).
Comment 38 Commit Notification 2020-12-08 16:31:54 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/9ee46e08c3155a59062d5d4975becc8b92d41626

tdf#134754: Gracefully handle EINVAL from mmap MAP_JIT on old macOS

It will be available in 7.0.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 39 Commit Notification 2020-12-08 17:04:25 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-7-0-4":

https://git.libreoffice.org/core/commit/9c8f43efc8e219c8b899c4f7478120b3b628b595

tdf#134754: Gracefully handle EINVAL from mmap MAP_JIT on old macOS

It will be available in 7.0.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 40 HTK300 2020-12-08 17:59:11 UTC
Created attachment 167984 [details]
apple crash dump #2
Comment 41 HTK300 2020-12-08 18:01:55 UTC
Hi,
I just downloaded LibreOffice 7.0.5 but the HSQLDB still crashes on [Tables] and [Queries].
using macOS 10.13 with java jre 1.8.0_271
Comment 42 HTK300 2020-12-08 18:07:47 UTC
Created attachment 167985 [details]
screenshot crashed LO
Comment 43 HTK300 2020-12-08 18:08:39 UTC
Created attachment 167986 [details]
select Tables
Comment 44 HTK300 2020-12-08 18:10:40 UTC
Created attachment 167987 [details]
JRE settings within LibreOffice preferences >advanced
Comment 45 Stephan Bergmann 2020-12-09 07:42:18 UTC
(In reply to HTK300 from comment #41)
> I just downloaded LibreOffice 7.0.5 but the HSQLDB still crashes on [Tables]
> and [Queries].

What exactly did you download from where?  There is no LO 7.0.5 out yet.
Comment 46 leoneo3000 2020-12-09 11:51:50 UTC
OK, the fixed builds are out now.

Confirmed fixed on macOS 10.13.6 in Master 7.2.0.0.alpha0+ (built 2020-12-09 03:25) build e4dc69b2b97dbd56bd55e514a5abcbd3c2a2f2fb
https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@tb81-TDF/2020-12-09_04.28.08/LibreOfficeDev_7.2.0.0.alpha0_MacOS_x86-64.dmg

Confirmed fixed on macOS 10.13.6 in Daily 7.1.0.0.beta1+ (built 2020-12-09 05:30) build 95765493c81e9ee4482638ded3e28f68c14cc83e
https://dev-builds.libreoffice.org/daily/libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2020-12-09_06.33.14/LibreOfficeDev_7.1.0.0.beta1_MacOS_x86-64.dmg

Confirmed fixed on macOS 10.13.6 in Daily 7.0.5.0.0+ (built 2020-12-09 07:33) build 9ee46e08c3155a59062d5d4975becc8b92d41626
https://dev-builds.libreoffice.org/daily/libreoffice-7-0/MacOSX-x86_64@tb81-TDF/2020-12-09_08.36.25/LibreOfficeDev_7.0.5.0.0_MacOS_x86-64.dmg

I consider this issue VERIFIED FIXED. Thanks for your work on this (and on the unrelated Firebird 3.0.7) Stephan!
Comment 47 Stephan Bergmann 2020-12-09 12:33:07 UTC
(In reply to leoneo3000 from comment #46)
> I consider this issue VERIFIED FIXED.

[updating status accordingly]
Comment 48 leoneo3000 2020-12-09 14:45:46 UTC
If you want I can test it on 7.0.4 too, as you say it should be fixed there too. I just couldn't find a build of 7.0.4 among the dev builds.

If you want me to test 7.0.4, give me a link and I'll do it today.
Comment 49 Stephan Bergmann 2020-12-09 15:08:57 UTC
(In reply to leoneo3000 from comment #48)
> If you want I can test it on 7.0.4 too, as you say it should be fixed there
> too. I just couldn't find a build of 7.0.4 among the dev builds.
> 
> If you want me to test 7.0.4, give me a link and I'll do it today.

I don't think there's any daily builds of LO 7.0.4, but according to <https://wiki.documentfoundation.org/ReleasePlan/7.0#7.0.4_release> an RC2 release candidate 7.0.4.2 should get built this week (and then show up in the prerelease versions at the bottom of <https://www.libreoffice.org/download/download/>) and announced as final next week (and then show up at the top of <https://www.libreoffice.org/download/download/>).  If you like, you can then test those too, but I'm pretty confident now that this issue should be fixed there as well.  But thanks for your offer!
Comment 50 HTK300 2020-12-09 21:41:30 UTC
(In reply to Stephan Bergmann from comment #45)
> (In reply to HTK300 from comment #41)
> > I just downloaded LibreOffice 7.0.5 but the HSQLDB still crashes on [Tables]
> > and [Queries].
> 
> What exactly did you download from where?  There is no LO 7.0.5 out yet.

Sorry the confusion, I do appologise...I cannot tell now but what I can do now is that LO 7.0.5 works fine on BASE now with my macOS 10.13
Harry
Comment 51 leoneo3000 2020-12-12 11:27:30 UTC
For completeness, I can confirm that it is indeed solved in the upcoming LO 7.0.4.2 as well.
Comment 52 Julien Nabet 2020-12-20 22:07:02 UTC
Let's simplify a bit targets.