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
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.
(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
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.
(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).
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?
(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 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.
(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.
A similar issue has been reported by another user on macOS 10.13 in bug 135975
*** Bug 135975 has been marked as a duplicate of this bug. ***
Given duplicate report on same macOS version, setting to new.
I see the bibisect request, but who is going to bibisect on macOS 10.13 ?
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.
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 2c366aae9263dc4115b054fe74b90cabea61fa0b source 2c366aae9263dc4115b054fe74b90cabea61fa0b :040000 040000 f4e33678d7824827d2d83eb14d15d244dacb955d 63fb87cdd42ce753dfc58eb884dfd6bd0317297a M LibreOffice.app
*** Bug 137076 has been marked as a duplicate of this bug. ***
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.
(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
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.
*** Bug 138670 has been marked as a duplicate of this bug. ***
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.
Created attachment 167849 [details] test executable
(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 2c366aae9263dc4115b054fe74b90cabea61fa0b > > source 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"); > } > }
(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.)
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.
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.
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.
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.
(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?
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.
(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).
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.
(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>
(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.)
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.
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.
Created attachment 167975 [details] screenshot LibreOffice java fyi
(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).
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.
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.
Created attachment 167984 [details] apple crash dump #2
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
Created attachment 167985 [details] screenshot crashed LO
Created attachment 167986 [details] select Tables
Created attachment 167987 [details] JRE settings within LibreOffice preferences >advanced
(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.
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!
(In reply to leoneo3000 from comment #46) > I consider this issue VERIFIED FIXED. [updating status accordingly]
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.
(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!
(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
For completeness, I can confirm that it is indeed solved in the upcoming LO 7.0.4.2 as well.
Let's simplify a bit targets.
*** Bug 139104 has been marked as a duplicate of this bug. ***