Bug 77141

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! :-)

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)

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.

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.

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).

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?

(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

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

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!

(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.

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

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 "

Adding self to CC if not already on