Created attachment 145097 [details] two odb test files This bug was filed from the crash reporting server and is br-f89809ad-2691-45e0-8f0c-81ef002bc329. ========================================= Running on Ubuntu 18.04 with Version: 6.1.1.1 Build ID: 2718b4a18dfcc6a54ebe5f7b801ee7a47fa81e0c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group threaded In this there are two copies of a Base file created with a Firebird embedded database. (I tried this with HSQL based files also and there is no problem with those, it is only the FB engine files) To reproduce grab to two attached files in the attached zip file and extract them. 1 Open one of the test files, establish a connection by going to the tables section and opening a table, or open the form. 2 Close this file. 3 Open the second test file. 4 File Save As and choose to save this file over the .odb file you just closed. 5. Now close the open ODB file, or close soffice. Crash On the terminal output is this: terminate called after throwing an instance of 'com::sun::star::lang::NotInitializedException'
Just ran this with 6.0.6 (the version that the original file was created in) and 6.2 Alpha 6.0.6 has no problem. 6.2Alpha also crashes, report is here crashreport.libreoffice.org/stats/crash_details/dc1533b5-b29b-449c-9f35-9f805e81a091
These observations from debian-buster: daily Linux dbgutil bibisect repository version 2018-09-22, and a local build of commit f74b8882 (2018-09-20) plus the (presumably irrelevant) patch set 7 from <https://gerrit.libreoffice.org/#/c/60048/>. I see the crash only if I browse table data in the first-opened file. Additionally in this case, the title of the database window still shows the name of the second-opened database file after I have saved it over the first-opened one. I am setting status NEW.
Created attachment 145220 [details] backtrace from "the" throw The ODatabaseDocument in question is the second constructed, the one constructed upon opening the second file (step 3). m_eInitState has value NotInitialized. I am setting keyword haveBacktrace.
(In reply to Terrence Enger from comment #2) > These observations from debian-buster: daily Linux dbgutil bibisect > repository version 2018-09-22, and a local build of commit f74b8882 > (2018-09-20) plus the (presumably irrelevant) patch set 7 from > <https://gerrit.libreoffice.org/#/c/60048/>. > > I see the crash only if I browse table data in the first-opened file. > Additionally in this case, the title of the database window still > shows the name of the second-opened database file after I have saved > it over the first-opened one. > > I am setting status NEW. yes - I should of come back and clarified that. The issue only triggers if a connection to the database has been established in the first document. In fact I believe there are couple of other issues open right now that look to have a root cause tied to the connection not being freed up as the document is closed. I could go find those and cross reference them or maybe this is worth a meta issue dealing with connection life cycle management?
(In reply to Drew Jensen from comment #4) > (In reply to Terrence Enger from comment #2) > > ... only if I browse table data ... > > yes - I should of come back and clarified that. The issue only triggers if a > connection to the database has been established in the first document. In I think that clicking <Tables> in the left pane to display the list of tables establishes the connection. Right? But I think I remember that that alone is not sufficient to trigger the later crash. > fact I believe there are couple of other issues open right now that look to > have a root cause tied to the connection not being freed up as the document > is closed. When I re-open the first file and browse table data a second time, lsof shows the same number of occurrences of fd's and they have the same value. So maybe maintenance of the connection is a deliberate optimization. I doubt that the optimization is needed, and it is clearly not being done right. This report immediately reminded me of bug 77141 "leaks a fd on closed odb: locks file on Windows share", but that is from 2014 and so is older than 6.0.6, which is said not to have the present problem. (The summary of bug 77141 is not quite right: the leak happens on Linux too, but Linux is more tolerant of operations on still-open files.) After Save-As but while the database window is still open, lsof showed me the first-opened file 8 times (all with the same value for the fd). > I could go find those and cross reference them or maybe this is worth a meta > issue dealing with connection life cycle management? Or, perhaps a bug for life cycle management in general. Do we have that already?
I can also reproduce it in Version: 5.3.0.0.alpha1+ Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: ca-ES (ca_ES.UTF-8); Calc: group
In(In reply to Xisco Faulí from comment #6) > I can also reproduce it in > > Version: 5.3.0.0.alpha1+ > Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c > CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; > Layout Engine: new; > Locale: ca-ES (ca_ES.UTF-8); Calc: group NOTE: in this version an empty error message is prompted while not in master
Checked this again today with Ubuntu 18.04 and Version: 6.1.4.0.0+ Build ID: 1c73f379bf8d6f75460790fec2993106e10f15a0 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-1, Time: 2018-11-21_23:30:33 Locale: en-US (en_US.UTF-8); Calc: group threaded Same crash as before, but with no actual crash report to send in. Version: 6.2.0.0.beta1 Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Same crash with a crash report: crashreport.libreoffice.org/stats/crash_details/1e20bd39-5aab-415a-97a6-49518dc96ad5 and Version: 6.3.0.0.alpha0+ Build ID: d8d231f97d829350d965105e3a5be119d1a6494c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-30_00:14:18 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded It works exactly as expected, no crash.
I still see the crash in daily Linux dbgutil bibisect repository version 2018-12-01 (s-h 099772a1) and local build of commit 7d459621 (2018-12-01 12:40:38 UTC). These are both dbgutil builds.
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! Warm Regards, QA Team MassPing-UntouchedBug
Working on debian-buster in a dbgutil local build of commit f717dcba (2019-12-27), losf shows that - LO closes all fd's to the .odb upon exiting the database window. - After save-as, all the fd's point to the saved-as filename. and there is, of course, no crash. There are lots of terminal messages, but that is not the problem of this bug report. I am setting bug status RESOLVED WORKSFORME.
(In reply to Terrence Enger from comment #11) > Working on debian-buster in a dbgutil local build of commit f717dcba > (2019-12-27), losf shows that > - LO closes all fd's to the .odb upon exiting the database window. > - After save-as, all the fd's point to the saved-as filename. > and there is, of course, no crash. > > There are lots of terminal messages, but that is not the problem of > this bug report. > > I am setting bug status RESOLVED WORKSFORME. Hi Drew Jensen, Could you please double check ?
Sure. Using Ubuntu 18.04.1 and Version: 6.4.0.1 Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: kf5; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Can not reproduce the crash or any problem. (will go back and check the latest updates to 6.3 and 6.2 and only come back here if either of them act differently)