I attempted to open the ODB file mentioned in bug 104227 :
Upon loading of the file, the test file fails to draw any UI elements other than a grey application window and the two white background window frames, per attached screenshot...
In addition, the remaining UI of the application becomes unresponsive to mouse clicks or keyboard activation. The only way to regain control is to force kill the application.
Steps to Reproduce:
1. Open ODB file indicated in description
Access and functionality to all usual UI objects should be possible. Currently, no work is possible with the embedded Firebird 3 ODB
User Profile Reset: No
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Created attachment 129179 [details]
UI on ODB file load
Just for information, I can't test anything about Base because of tdf#103667
I can't open or create Base file (Hsqldb or Firebird).
I can open and edit tables, but not create a new one, all task are greyed out for tables, queries, forms and reports.
Build ID: 172325bedf69bbc162f3c1948264451c90c105a3
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new;
TinderBox: Win-x86@39, Branch:master, Time: 2016-11-21_05:26:40
Locale: es-ES (es_ES); Calc: group
Tested this with
Build ID: 150afc29c951d5fc9c40ff8a72f5178c32383f8c
CPU Threads: 4; OS Version: Linux 4.1; UI Render: default; VCL: kde4;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-12-03_01:02:49
Locale: de-DE (de_DE.UTF-8); Calc: group
Couldn't reproduce with OpenSUSE 42.1 64bit rpm Linux.
On macOS 10.12.1 with master sources updated yesterday, I could give a try after having disabled autorecovery (which makes LO crash)
I don't reproduce the problem.
(In reply to Julien Nabet from comment #5)
> On macOS 10.12.1 with master sources updated yesterday, I could give a try
> after having disabled autorecovery (which makes LO crash)
> I don't reproduce the problem.
Yes, disabling the autosave feature enabled me to open the file and tables. So, this behaviour is linked to bug 104227, in which case, I shall try it again (with autosave re-activated, after I have rebuilt from master.
Alex: any update about this tracker?
I think that if it works with autorecovery disabled, it means that the pb is only tdf#103515.
Comment#3 issue doesn't happen now with:
Build ID: 2e9c02feca732f6dd012ccbe5d7c6853c64075a5
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default;
TinderBox: Win-x86@39, Branch:master, Time: 2016-12-20_00:19:54
Locale: es-ES (es_ES); Calc: CL
@Julien : still a problem for me on OSX when I re-activate autosave on
CPU Threads: 2; OS Version: Mac OSX 10.12.1; UI Render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group
If the StartCenter is already open and displaying on screen and I try to open a FB3 file from the recent file list, nothing happens - no ODB file is loaded, the StartCenter dialog becomes unresponsive.
I can however force reload or refresh the app by opening the same file via the LibreOffice File > Recent menu - this then swaps the StartCenter window for the Base window, however, that window is now non-responsive to mouse clicks or key strokes.
Attempting to quit LibreOffice via the menu fails, nothing happens.
If I drag and drop the ODB file directly onto the LO app icon in the OSX Dock, the Base window frame gets drawn incompletely, the same as in the attached file I had already posted.
De-activating autosave again, and restarting LO allows me to open the FB3 ODB file correctly once more.
Note that I'm using a debug-enabled build
Created attachment 129842 [details]
Screenshot when running Lodev under lldb
I took a screenshot of what the app looks like when running under lldb when it attempts to draw various UI elements of the FB3 ODB file with autosave turned off.
Created attachment 129843 [details]
lldb session output with bt
Also enclosed a bt of the lldb session - the mutex yield dbg assert is there, but there appear to be other problems.
Alex: could you give an update with autosave enabled?
The daily build you use must contain https://cgit.freedesktop.org/libreoffice/core/commit/?id=b2c467e47f438b2011aa304cca9bf403eaa1c8e2
Build ID: 40fb49446b456459a4cdfa6fff0013b7ffef82e8
CPU Threads: 2; OS Version: Mac OS X 10.12.2; UI Render: default;
Locale: fr-FR (fr_FR.UTF-8); Calc: group
the test file doesn't even load any more, when AutoSave is turned on, I just see the StartCenter with the grey background indicating that I've clicked the file to load it. I have to force quit the application, none of the menus respond.
If I ignore the StartCenter (e.g. close it) and then drag and drop the test file onto the LO icon in the Dock, again, nothing happens, the file doesn't load, and I'm left with a running LO application in an indeterminate state. If I then repeat the drag and drop maneuver, I get the same incomplete UI of the main Base app window as obtained previously and shown with my screenshot.
(In reply to Alex Thurgood from comment #18)
> the test file doesn't even load any more, when AutoSave is turned on, I just
> see the StartCenter with the grey background indicating that I've clicked
> the file to load it. I have to force quit the application, none of the menus
Any chance for a new stacktrace to see if it's still the same.
On MacOs 10.12.2, with master sources updated 2 days ago and autorecovery enabled, I could open the file and opened the tables.
My autogen.input contains this:
--with-lang=en-US it fr de es pt ru cs hu pl nl
Confirmed working correctly for me in
Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3
Threads CPU : 4; Version de l'OS :Mac OS X 10.12.5; UI Render : par défaut; Moteur de mise en page : nouveau;
Locale : fr-FR (fr_FR.UTF-8); Calc: group