Bug 117352 - Firebird: Migration: LibO does not fully release file when ODB file closed without saving after failed migration attempt until LibO session is closed.
Summary: Firebird: Migration: LibO does not fully release file when ODB file closed wi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
Hardware: All All
: high major
Assignee: Not Assigned
Depends on:
Blocks: Database-Firebird-Migration
  Show dependency treegraph
Reported: 2018-04-30 15:07 UTC by Drew Jensen
Modified: 2021-09-05 04:35 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

odb which triggers auto-migrate error (94.53 KB, application/vnd.oasis.opendocument.database)
2018-04-30 15:10 UTC, Drew Jensen
list of soffice process open files (142.65 KB, image/png)
2018-04-30 16:29 UTC, Drew Jensen
process open files after ODB save (127.65 KB, image/png)
2018-04-30 16:47 UTC, Drew Jensen
another test file (5.16 KB, application/vnd.oasis.opendocument.database)
2018-05-30 16:19 UTC, Drew Jensen
Another ddbb affected (13.24 KB, application/vnd.oasis.opendocument.database)
2018-07-04 14:41 UTC, Xisco Faulí

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-04-30 15:07:05 UTC
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.
Tested with:
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.

Actual Results:  
The file is opened and status bar indicated this is a firebird database, but it is not. 

Expected Results:
The file is opened and recognized as HSQLdb database.

Reproducible: Always

User Profile Reset: No

Additional Info:

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
Comment 1 Drew Jensen 2018-04-30 15:10:42 UTC
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.
Comment 2 Drew Jensen 2018-04-30 16:25:58 UTC
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.
Comment 3 Drew Jensen 2018-04-30 16:29:49 UTC
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.
Comment 4 Drew Jensen 2018-04-30 16:42:31 UTC
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.
Comment 5 Drew Jensen 2018-04-30 16:47:46 UTC
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.
Comment 6 Alex Thurgood 2018-05-02 06:53:28 UTC
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 ?
Comment 7 Alex Thurgood 2018-05-02 06:55:07 UTC
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.
Comment 8 Drew Jensen 2018-05-30 16:19:54 UTC
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
Comment 9 Xisco Faulí 2018-07-04 14:41:11 UTC
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...
Comment 10 Tamas Bunth 2018-07-17 12:14:45 UTC

Since this commit[1], 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.

[1] 9ceeb4619ba762c47589023d99c43c774caab441
Comment 11 Xisco Faulí 2018-09-03 19:30:15 UTC
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
Comment 12 Xisco Faulí 2018-09-03 19:34:07 UTC
(In reply to Tamas Bunth from comment #10)
> Hi,
> Since this commit[1], the bug is fixed, as far as I see.
> [1] 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...
Comment 13 Julien Nabet 2018-09-04 19:44:09 UTC
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>&)
    type: com.sun.star.uno.DeploymentException
    message: component context fails to supply service com.sun.star.io.TempFile of type com.sun.star.io.XTempFile
    context: cppu::ComponentContext

warn:dbaccess:19545:19545:dbaccess/source/core/dataaccess/ModelImpl.cxx:757: ODatabaseModelImpl::commitRootStorage: could not commit the storage!
Comment 14 QA Administrators 2019-09-05 09:34:34 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2021-09-05 04:35:28 UTC
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 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

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

Warm Regards,
QA Team