Bug 98491 - Split hsqldb Base application will not start under OSX10.11.x causes LO to freeze requiring force kill
Summary: Split hsqldb Base application will not start under OSX10.11.x causes LO to fr...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: All macOS (All)
: high major
Assignee: Not Assigned
Keywords: bibisectRequest, haveBacktrace, regression
: 98591 (view as bug list)
Depends on:
Blocks: Database-HSQLDB
  Show dependency treegraph
Reported: 2016-03-07 11:53 UTC by jay Arr
Modified: 2022-11-30 20:16 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Unzip into sub-dir - files are required to support split database (9.16 MB, application/zip)
2016-03-07 12:42 UTC, jay Arr
full bt debug build osx 10.11.3 (30.05 KB, text/plain)
2016-03-11 11:14 UTC, Alex Thurgood

Note You need to log in before you can comment on or make changes to this bug.
Description jay Arr 2016-03-07 11:53:43 UTC

Comment 1 jay Arr 2016-03-07 12:42:02 UTC
Created attachment 123376 [details]
Unzip into sub-dir - files are required to support split database

This is a stripped down version of the application without all the supporting data files. It will startup. If you require the full application see the web site www.secretarybird.info
Comment 2 jay Arr 2016-03-07 15:21:04 UTC
The attached SPLIT .odb LO database file will not startup & run with either the latest FRESH or STLL version of LO whilst running under OSX10.11.*.

The database WIL start up and run with either the latest FRESH or STILL version of LO whilst running under any OSX10.* (as long as it's NOT 10.11.*) AND it will run UNCHANGED on Windows 7,8 or 10 with LO FRESH or STILL.


The GUI appears
the bottom line of the window is completed with the URL of the database
a blue line flashes across the bottom of the windows for about 5 seconds
the application and LO freezes. Cannot do a force quit - have to run Apple's ActivityMonitor where the LO process is using over 100% of the cpu and quit from there.

I hace tried
various JRE combinations both latest 1.8.0_73(66) wit and without Apple's last java download javaforosx.dmg dated 31-Aug-2015. I've delete my user profile dir from the '4'  sub-dir and restsrted LO. None of which worked.

I have tried putting trace calls to msgbox in the first macro that's run by the application called SETUP in the 'embedded' module - they are never called. I think the problem relates to the OSX10.11.* and the initialisation that LO goes through prior to initiating a database. 

The attached file is a stripped down core of the free production application you can find at www.secretarybird.info.  NB the AppleMAC installation files have been disabled for OSX10.11

When the .odb file does run you will see the application's splash form and then a switchboard form with empty buttons.
Comment 3 Alex Thurgood 2016-03-11 10:54:21 UTC
There are several potential problems :

- you need a full Java JDK to be installed - JRE 1.8 alone is no longer recognized ;

- you need to specifically add the hsqldb jar to the Advanced properties configuration dialog, under Add Archive, if you add just the folder that points to sqltool.jar and hsqldb.jar, the ODB will load, but the welcome screen will not ;

- there is a known bug with certain macro events misfiring or not firing at all on load of LO for OSX - I don't have the bug reference to hand.

Tested on OSX 10.11.3.
I can open the ODB, I can see the welcome screen with the bird icon button.
After that the app freezes and steadily consumes all available resources. A force kill is required to regain control of the machine.

Please separate out the problems and file separate reports for each one. At the moment, with the configuration I outlined above, I can open the file at least.
Comment 4 Alex Thurgood 2016-03-11 11:12:56 UTC
Confirming that attempting to open the split database causes LO 52 master debug build to freeze as well, including backtrace
Comment 5 Alex Thurgood 2016-03-11 11:14:15 UTC
Created attachment 123495 [details]
full bt debug build osx 10.11.3
Comment 6 Alex Thurgood 2016-03-11 11:37:02 UTC
*** Bug 98591 has been marked as a duplicate of this bug. ***
Comment 7 jay Arr 2016-03-23 10:23:49 UTC
I have followed the advice: installed the full JDK and specifically added the hsqldb jar.

I get the same result as originally reported. This ONE problem NOT two. 

Let me restate the problem: both Fresh & STILL versions of LO do not properly handle the startup of this .odb when it is run under OSX10.11.*.

For the avoidance of doubt the identical .odb works fine with all other versions of OSX, Windows 7,8 & 10 and Ubuntu and with all versions of LO.

My diagnosis is that OSX10.11.* & LO do not work well together and do not work as consistently as with other operating systems. 

This leads me to the conclusion that there is an inherent problem with LO and specifically OSX10.11.* In support of this argument you will be aware that this is not the only problem that has been reported with these conditions.
Comment 8 frofa 2016-03-24 04:42:02 UTC
I have been able to duplicate the problem behaviour as described by jay_Arr (on MacOSX 10.11.4).

For what it's worth, there is no hang when I run the Base app. with MACROS DISABLED - I can see all TABLES, QUERIES, FORMS, REPORTS as listed and also open all those elements I have tried so far (though I realize it is likely that certain functionality might be lost without macros enabled). So it would seem reasonable hypothesis that the root cause of the problem is the initialization macro(s). I should also say that I had to also manually re-set the PATH to the files in the database PROPERTIES (different from the path that had been set as default) to match the app location on my system. I guess the initialization macro would do that automatically?
Comment 9 jay Arr 2016-04-08 06:42:13 UTC
I would be very grateful if this could be given some attention and possible resolution. It's embarrassing for an public application and advertisement for LO Base (that requests users to make a donation to charity) to be able to run on all system except a particular version of OSX.
Comment 10 Alex Thurgood 2016-05-20 07:44:19 UTC
@Jay : quite possibly, the macro execution at launch is adding to, or is the root cause, of the problem, as indicated by frofa's comments where he indicated that turning off macros and manually resetting the path allowed the db file to open.

See this bug for more details on the macro problem :


If your database startup configuration relies on dialogs or windows being initiated or displayed in an event loop, then you will be hit by bug 95191.
Comment 11 Alex Thurgood 2016-06-16 08:52:26 UTC
Works fine with 

Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: fr.UTF-8

==> regression
Comment 12 Alex Thurgood 2016-08-31 09:32:22 UTC
This is where the app stops responding :

* thread #34: tid = 0x6bebb6, 0x00000001018caa6c libsblo.dylib`SbiExprList::IsValid() + 12, stop reason = EXC_BAD_ACCESS (code=1, address=0x1a)
    frame #0: 0x00000001018caa6c libsblo.dylib`SbiExprList::IsValid() + 12
->  0x1018caa6c <+12>: movb   0x1a(%rdi), %al
    0x1018caa6f <+15>: xorb   $0x1, %al
    0x1018caa71 <+17>: andb   $0x1, %al
    0x1018caa73 <+19>: movzbl %al, %eax
Comment 13 Xisco Faulí 2016-09-13 09:29:53 UTC
Adding keyword 'bibisectRequest'
Comment 14 Xisco Faulí 2017-09-29 08:52:30 UTC Comment hidden (obsolete)
Comment 15 Buovjaga 2018-05-25 11:21:09 UTC
If I try to open it on Linux I get "Error non-fatal" dialog

| XcDate
|  Parameters:
|  1={21/01/16}
| ERROR @ line no.39
|  Data type mismatch.
|  Extra info. Abandoning execution!

I click Continue, but nothing happens. Closing the dialog helps.

No freezing.

Arch Linux 64-bit
Build ID: eeaf6dee2d278eaa037d95a756ad0ffab3314bc2
CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on May 24th 2018
Comment 16 QA Administrators 2019-05-26 02:51:56 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2022-09-27 03:32:37 UTC
Dear jay Arr,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team