Bug Hunting Session
Bug 77141 - leaks a fd on closed odb: locks file on Windows share
Summary: leaks a fd on closed odb: locks file on Windows share
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.1.4.2 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: File-Lock
  Show dependency treegraph
 
Reported: 2014-04-07 15:19 UTC by Lionel Elie Mamane
Modified: 2019-08-31 19:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Valgrind trace with --track-fds=yes (35.91 KB, application/x-bzip)
2014-05-31 13:48 UTC, Julien Nabet
Details
lsof after creating embedded HSQLDB database (1.93 KB, text/plain)
2015-06-05 13:45 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2014-04-07 15:19:25 UTC
Open foo.odb file (tested with a HSQL embedded file), do some work in it.
Close the file.

Result: LibreOffice still has an open fd on foo.odb

Expected result: LibreOffice closes all its open fds on foo.odb

TODO: test with a non-embedded odb file.

This becomes extremely annoying when foo.odb is on a CIFS mount actually served by a Windows computer, since it is exclusively locked by that open fd AND NO ONE CAN OPEN IT ANYMORE, not even the LibreOffice that has the leaked fd (probably since it tries to open a new fd for the same file, but the exclusive locking makes that fail).
Comment 1 Julien Nabet 2014-04-07 16:54:26 UTC
On pc Debian x86-64 with master sources updated today and 4.2 updated some days ago, I don't reproduce this.
Now here's the simple test I made:
- Open 2 consoles
- console 1 : open an empty hsqldb file on LO
- console 2 : lsof|grep <name of the file>, about 20 lines

- console 1 : close the hsqldb file (after having done nothing on it I must recognize)
- console 2 : the same lsof command gives nothing

Since the only remaining 4.1 version to be released is 4.1.6, I think it could be useful you give a try to 4.2.2
If you can't, could you try to find the minimal steps to reproduce this?

BTW, I build in debug mode so if you want me to test something to retrieve console logs, don't hesitate! :-)
Comment 2 Lionel Elie Mamane 2014-04-10 13:48:17 UTC
Further testing shows:

 1) Not reproducible with *empty* HSQLDB; need a table in the database.
    (The table itself can be empty, though.)

 2) Reproducible on one of my machines, but not on the other.
    Both amd64 Debian machines... different versions, though.
    (same LibreOffice version)

 3) Not reproducible on LibreOffice 4.2.3.3 (TDF build)
Comment 3 Lionel Elie Mamane 2014-04-10 14:04:18 UTC
No, even further testing shows that the bug is just more elusive than I thought:

 1) Reproducible on *both* machines

 2) With 4.1 *and* with 4.2

I "found" the bug in real-life scenarios, but here is a synthetic one that always works (reproduces the bug):

 1) Start with an empty .odb

 2) Use wizard to create a table

 3) Category: Business / Sample Tables: Assets / Select all field

    Next

 4) Next again

 5) Use an existing field as primary key: AssetID, "Auto value" *checked*

    Next

 6) Insert data immediately

    Finish

 7) Do not insert any data. Close the Table Window.

 8) Close the database window


By contrast, reopening the same .odb, entering data in the table and then closing does not trigger the bug.
Comment 4 Lionel Elie Mamane 2014-04-10 14:14:05 UTC
Obviously, one needs to have another LibreOffice window (e.g. a writer document) open during the proceedings to reproduce the bug; else the soffice(.bin) process exits and obviously the fd is closed then.
Comment 5 Julien Nabet 2014-04-10 20:25:05 UTC
I gave a try with step by step process of comment 3 but I didn't reproduce this.
However, it was with master sources updated today.

I'll try to find some time to give a try with 4.2 sources (that I must build first).
Comment 6 Julien Nabet 2014-05-30 22:35:55 UTC
I don't reproduce this with 4.2 sources updated 2 days ago or with 4.2.4 LO Debian package, I don't reproduce this.

BTW, do you register the DB? Do you save odb file when closing?
Comment 7 Lionel Elie Mamane 2014-05-31 02:48:46 UTC
(In reply to comment #6)
> I don't reproduce this with 4.2 sources updated 2 days ago or with 4.2.4 LO
> Debian package, I don't reproduce this.

> BTW, do you register the DB?

No.

> Do you save odb file when closing?

Yes.


I just re-reproduced with master updated yesterday:

Author: Markus Mohrhard <markus.mohrhard@googlemail.com>  2014-05-30 05:15:01
Committer: Markus Mohrhard <markus.mohrhard@googlemail.com>  2014-05-30 05:16:46

    remove fsanitize=address from libgetuid.so makefile
    
    Change-Id: I3d292638b76ed09d84df36d096f70c9496a23fdf
Comment 8 Lionel Elie Mamane 2014-05-31 03:15:17 UTC
To check for the leaked fd, do (after closing the .odb):

$ lsof -p$(pidof soffice.bin)|grep odb_file_name
soffice.b 17515 user   85uW  REG                9,1      3323  45679326 /home/user/New Database.odb
Comment 9 Julien Nabet 2014-05-31 07:56:59 UTC
Perhaps it's because I use debug mode but I still can't reproduce by following comment3 :( (master sources updated today)

lsof -p$(pidof soffice.bin)|grep julien1
lsof: no process ID specified

Just noticed these logs:
warn:legacy.osl:21163:1:dbaccess/source/core/dataaccess/ModelImpl.cxx:895: caught an exception!
in function: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: N4cppu16ComponentContextE

warn:legacy.osl:21163:1:dbaccess/source/core/dataaccess/ModelImpl.cxx:804: ODatabaseModelImpl::commitRootStorage: could commit the storage!
Comment 10 Lionel Elie Mamane 2014-05-31 08:44:26 UTC
(In reply to comment #9)
> Perhaps it's because I use debug mode but I still can't reproduce by
> following comment3 :( (master sources updated today)

> lsof -p$(pidof soffice.bin)|grep julien1
> lsof: no process ID specified


This looks like you don't have any LibreOffice running. Did you see comment 4? You cannot let LibreOffice exit, so you must have some *other* document (any, Calc, Writer, Base, Impress, ...) open at the same time, that you do *not* close.
Comment 11 Julien Nabet 2014-05-31 10:22:23 UTC
You're right! I was focused on comment3 and had overlooked comment4.
I could reproduce the problem and lsof|grep <filename> gives:
24 lines:
- 18 soffice.b
- 1 rtl_cache
- 1 OfficeIPC
- 1 gdbus
- 1 ICEConnec
- 1 Selection
- 1 gmain
Comment 12 Julien Nabet 2014-05-31 13:48:19 UTC
Created attachment 100200 [details]
Valgrind trace with --track-fds=yes

Here's a Valgrind trace with "--track-fds=yes" added in this line in instdir/program/soffice:
VALGRINDCHECK="valgrind --tool=$VALGRIND --track-fds=yes --trace-children=yes $valgrind_skip --num-callers=50 --error-limit=no "
Comment 13 Alex Thurgood 2015-01-03 17:40:16 UTC Comment hidden (no-value)
Comment 14 Terrence Enger 2015-06-03 20:07:31 UTC
I see that retained open file on Windows Vista with LibreOffice ...
    Version: 5.1.0.0.alpha1+
    Build ID: 21a6b99748db8a970ef7dc90d40e07901135b89a
    TinderBox: Win-x86@39, Branch:master, Time: 2015-06-03_05:45:39
    Locale: en-CA (en_CA)
as indicated by my inability to delete the file after closing its window.

The behavior on Linux is different: at least once I was able to delete
the .odb while the LibreOffice window was still open.
Comment 15 Terrence Enger 2015-06-03 20:08:40 UTC
I should have said:  my .odb was on the local disk.
Comment 16 Lionel Elie Mamane 2015-06-04 04:23:34 UTC
(In reply to Terrence Enger from comment #14)
> I see that retained open file on Windows Vista with LibreOffice ...
>     Version: 5.1.0.0.alpha1+
>     Build ID: 21a6b99748db8a970ef7dc90d40e07901135b89a
>     TinderBox: Win-x86@39, Branch:master, Time: 2015-06-03_05:45:39
>     Locale: en-CA (en_CA)
> as indicated by my inability to delete the file after closing its window.
> 
> The behavior on Linux is different: at least once I was able to delete
> the .odb while the LibreOffice window was still open.

That's a OS difference, not (necessarily) a LibreOffice difference. On Unix/Linux, one can delete an open file (it disappears from the directory, but it stays "under the hood" and is automatically deleted when it is closed); on Windows one cannot delete an open file.
Comment 17 Terrence Enger 2015-06-05 13:45:08 UTC
Created attachment 116307 [details]
lsof after creating embedded HSQLDB database

Sheesh.  Once again I have managed to overlook the obvious.

The files appear to be left open after the database wizard creates the
file, 17 after creating embedded HSQLDB, 9 after creating embedded
Firebird.
Comment 18 QA Administrators 2016-09-20 09:46:29 UTC Comment hidden (obsolete)
Comment 19 Lionel Elie Mamane 2016-11-24 15:40:21 UTC
still reproduced in 5.2.3.1 (Debian package)
Comment 20 QA Administrators 2017-11-25 09:43:05 UTC Comment hidden (obsolete)
Comment 21 Terrence Enger 2017-12-01 16:48:31 UTC
lsof still shows newly created .odb files left open after I close the
Base window.  Indeed there seem to be 17 fd's left open, both embedded
firebird and embedded hsqldb, both if I go directly into edit database
(without making any changes) or not.

These observations are with daily linux dbgutil bibisect repository
version 2017-12-01 running on debian buster.
Comment 22 QA Administrators 2018-12-03 03:58:17 UTC Comment hidden (obsolete)
Comment 23 Terrence Enger 2018-12-22 21:00:23 UTC
Working on debian-buster in daily Linux dbgutil bibisect repository
version 2018-12-18, I created a new embedded Firebird database and one
table.  After I close the .odb and LibreOffice displays Start Center,
lsof shows the .odb file open 8 times.