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
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.
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.
Confirming that attempting to open the split database causes LO 52 master debug build to freeze as well, including backtrace
Created attachment 123495 [details]
full bt debug build osx 10.11.3
*** Bug 98591 has been marked as a duplicate of this bug. ***
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.
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?
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.
@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.
Works fine with
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
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
Adding keyword 'bibisectRequest'
** Please read this message in its entirety before responding **
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 on a currently supported version of LibreOffice
(5.4.1 or 5.3.6 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
If I try to open it on Linux I get "Error non-fatal" dialog
| STACK DUMP
| ERROR @ line no.39
| Data type mismatch.
| Extra info. Abandoning execution!
I click Continue, but nothing happens. Closing the dialog helps.
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