Bug 77141

Summary: leaks a fd on closed odb: locks file on Windows share
Product: LibreOffice Reporter: Lionel Elie Mamane <lionel>
Component: DatabaseAssignee: Not Assigned <libreoffice-bugs>
Status: NEW --- QA Contact:
Severity: major    
Priority: medium CC: iplaw67, serval2412
Version: 4.1.4.2 release   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Valgrind trace with --track-fds=yes

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
Adding self to CC if not already on

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.