If an ODB fails to finish a auto-migration and is closed without saving subsequent attempts to open the file will render a useless file, treated by Base as if it has an embedded firebird database but with no tables, until the Libo session is ended and the application restarted.
Build ID: 4dbce627d3643babaf90a93c70b365ff08abfca6
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-28_22:03:31
Locale: en-US (en_US.UTF-8); Calc: group
Steps to Reproduce:
1. Open attached ODB file
2. Select Tables and begin an auto migration
3. Close the error message box displayed
4. Close the ODB file without saving it
5. Reopen the ODB file.
The file is opened and status bar indicated this is a firebird database, but it is not.
The file is opened and recognized as HSQLdb database.
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Created attachment 141791 [details]
odb which triggers auto-migrate error
Any HSQL embedded file would work, as long as it triggers an SQL error during auto-migrate. If the migration function works to completion this behavior does not manifest.
Alright - so I did a little digging here and started watching what files were opened by the soffice process.
What I found is that a number of firebird files are opened and if no error during migration all are closed when the file is closed.
BUT when an error is triggered the file
is also opened and that file is not closed when the odb file is closed.
Created attachment 141793 [details]
list of soffice process open files
The screen shot is of the files opened by soffice after the odb file, which failed to auto-migrate, was closed.
Came at it another way.
I used an hsql file that I knew would migrate with no errors, so it is running the fb engine.
After migration and while still not saved I created a nonsensical sql statement in query designer and ran it, triggered SQL error.
Now I close the file without saving it and behaves just as in the original report and once more the firebird.msg file is left open after the ODB has been closed.
There are those couple of /tmp files for firebird taces etc also left open.
Created attachment 141794 [details]
process open files after ODB save
here is the screen shot of the processes open files after the odb file was success in migration, but subsequent sql error displayed from designer and then closed without saving.
Again, both the firebird.msg file (no. 36) is left open as is the odb file itself (no. 26), even though it is closed in GUI.
So, I vaguely recollect that writing to firebird.msg was originally included with the embedded engine so that it would be easier to find the FB error message in case of a problem. I don't suppose it should remain open if the UI document is released, and I guess that the reason the ODB file still shows as open in the lsof is because firebird.msg hasn't been released.
@Tamas : Is this a destructor issue or a mutex release issue ?
Or alternatively, perhaps this is working as designed ? Seems a bit strange that resource allocation should continue once the UI has removed the ODB document.
Created attachment 142416 [details]
another test file
I tried this file also, and even without an error, and on my Ubuntu 18.04 and 6.1Beta1 it behaves this way
Created attachment 143309 [details]
Another ddbb affected
I found I case when this is happening:
1. Open attached ddbb
2. Go to table and migrate
3. Close the ddbb without saving
4. Open the database again
-> Observed behaviour: the table is no longer available under table...
Since this commit, the bug is fixed, as far as I see.
I couldn't reproduce the bug with:
Build ID: 6203974c2dfa9e3b4bd4a5f52bc5394e29669342
CPU threads: 4; OS: Linux 4.17; UI render: default; VCL: gtk3;
I marked it as resolved/fixed.
This issue is still reproducible in
Build ID: 4b5fcd417587cfb9e6d8b61ecb037ab165eeb5b9
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
1. Open https://bugs.documentfoundation.org/attachment.cgi?id=144513
2. Go to table and click on yes to do the migration
3. Click on Contacts table
4. Close the table and the database without closing LibreOffice. DO NOT SAVE the changes
5. Open the same database again
6. Go to table
Observed behaviour: The migration dialog is not displayed and the contacts table is gone
(In reply to Tamas Bunth from comment #10)
> Since this commit, the bug is fixed, as far as I see.
>  9ceeb4619ba762c47589023d99c43c774caab441
Just in case, I've tried with the same exact commit
Build ID: 9ceeb4619ba762c47589023d99c43c774caab441
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
and the steps from comment 11 are also reproducible...
To be sure, I tested it with a clear profile...
On pc Debian x86-64 with master sources updated today, I don't reproduce this.
I gave a try to comment 11.
The second time I open the file, the migration dialog appears.
I just noticed this on console when closing main window:
warn:dbaccess:19545:19545:dbaccess/source/core/dataaccess/ModelImpl.cxx:853: DBG_UNHANDLED_EXCEPTION in static bool dbaccess::ODatabaseModelImpl::commitStorageIfWriteable_ignoreErrors(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage>&)
message: component context fails to supply service com.sun.star.io.TempFile of type com.sun.star.io.XTempFile
warn:dbaccess:19545:19545:dbaccess/source/core/dataaccess/ModelImpl.cxx:757: ODatabaseModelImpl::commitRootStorage: could not commit the storage!
Dear Drew Jensen,
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!