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