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
opt/firebird/firbird.msg
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...

Hi,

Since this commit[1], the bug is fixed, as far as I see.

I couldn't reproduce the bug with:
Version: 6.2.0.0.alpha0+
Build ID: 6203974c2dfa9e3b4bd4a5f52bc5394e29669342
CPU threads: 4; OS: Linux 4.17; UI render: default; VCL: gtk3; 

I marked it as resolved/fixed.

[1] 9ceeb4619ba762c47589023d99c43c774caab441

This issue is still reproducible in

Version: 6.2.0.0.alpha0+
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)
> 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

Version: 6.2.0.0.alpha0+
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>&)
    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!

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://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug