Bug Hunting Session
Bug 120042 - FIREBIRD: Crash in: libc-2.27.so when Save As of an ODB overtop of an existing ODB if the target has been opened in current session
Summary: FIREBIRD: Crash in: libc-2.27.so when Save As of an ODB overtop of an existin...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.3 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: Database-Firebird-Default
  Show dependency treegraph
 
Reported: 2018-09-21 20:49 UTC by Drew Jensen
Modified: 2018-12-01 23:21 UTC (History)
2 users (show)

See Also:
Crash report or crash signature: ["libc-2.27.so"]


Attachments
two odb test files (18.26 KB, application/zip)
2018-09-21 20:49 UTC, Drew Jensen
Details
backtrace from "the" throw (6.16 KB, text/plain)
2018-09-27 15:30 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-09-21 20:49:53 UTC
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'
Comment 1 Drew Jensen 2018-09-21 20:59:21 UTC
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
Comment 2 Terrence Enger 2018-09-27 15:28:33 UTC
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.
Comment 3 Terrence Enger 2018-09-27 15:30:56 UTC
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.
Comment 4 Drew Jensen 2018-09-27 15:40:32 UTC
(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?
Comment 5 Terrence Enger 2018-09-27 17:43:53 UTC
(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?
Comment 6 Xisco Faulí 2018-10-17 11:35:38 UTC
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
Comment 7 Xisco Faulí 2018-10-17 11:38:10 UTC
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
Comment 8 Drew Jensen 2018-12-01 17:00:46 UTC
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.
Comment 9 Terrence Enger 2018-12-01 23:21:06 UTC
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.