The error dialog very exactly says:

General Error.
General input/output error.

This problem is specific to .odt files and does not happen with .doc or .txt files.

If file is copied to a local filesystem, it works well and this bug does not appear.

This patch resolves the issue, removing the fcntl call:


--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -1033,7 +1033,7 @@ SAL_CALL osl_openFilePath( const char *cpFilePath, oslFileHandle* pHandle, sal_u
             aflock.l_start = 0;
             aflock.l_len = 0;
 
-            if (-1 == fcntl (fd, F_SETLK, &aflock))
+            if (-1 == 0)
             {
                 int saved_errno = errno;
                 OSL_TRACE("osl_openFile(%s, %s): fcntl(%d, F_SETLK) failed: %s",


It probably breaks other things and is not the right fix, but it confirms that the culprit is the fcntl call in the strace and the "idea" of opening the file twice!

Hi Lionel - thanks for the great debugging here ! :-)

Opening a file multiple times and fiddling with it is really par for the course :-) in general, we only worry about it if there is a demonstrable performance problem coming from it.

Anyhow - in this case, I guess we need to get two stack-traces: of the first time the file is opened, and the second - I imagine the first one should be closed before the second is opened: at least if they're both exclusive ;-) presumably something subtle changed there.

Any chance of a pair of traces of that with symbols ? :-)

Thanks !

Reproduced with .ods file (OpenDocument spreadsheet).

Will try to provide the requested backtraces in a few days.

i've fixed something related in 0c2206081de38a41597aadfb2255540d6308be63
but that one struck on WNT only...

trying it with a local file i get first open from type detection
filling the XInputStream in the Media Descriptor:

#0  open64 () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f1a5cb64740 in osl_openFilePath (cpFilePath=0x7fff7845bb50 "/Documents/RGBA PNG.odt", pHandle=0x305e8e0, uFlags=3) at /master/sal/osl/unx/file.cxx:914
...
#10 0x00007f1a5919dd38 in ucbhelper::Content::openWriteableStream (this=0x7fff7845d0a0) at /master/ucbhelper/source/client/content.cxx:765
#11 0x00007f1a5c44fe10 in comphelper::MediaDescriptor::impl_openStreamWithURL (this=0x7fff7845d7d0, sURL="file:///Documents/RGBA%20PNG.odt", bLockFile=1 '\001') at /master/comphelper/source/misc/mediadescriptor.cxx:610
#12 0x00007f1a5c44efdb in comphelper::MediaDescriptor::impl_addInputStream (this=0x7fff7845d7d0, bLockFile=1 '\001') at /master/comphelper/source/misc/mediadescriptor.cxx:469
#13 0x00007f1a5c44ec66 in comphelper::MediaDescriptor::addInputStreamOwnLock (this=0x7fff7845d7d0) at /master/comphelper/source/misc/mediadescriptor.cxx:435
#14 0x00007f1a3f586b3b in filter::config::TypeDetection::impl_openStream (this=0x299e710, rDescriptor=...) at /master/filter/source/config/cache/typedetection.cxx:1184
#15 0x00007f1a3f5861eb in filter::config::TypeDetection::impl_askDetectService (this=0x299e710, sDetectService="com.sun.star.text.FormatDetector", rDescriptor=...) at /master/filter/source/config/cache/typedetection.cxx:1029
Traceback (most recent call last):
  File "/lib64/../share/gcc-4.7.2/python/libstdcxx/v6/printers.py", line 103, in children
    nodetype = find_type(self.val.type, '_Node')
  File "/lib64/../share/gcc-4.7.2/python/libstdcxx/v6/printers.py", line 43, in find_type
    field = typ.fields()[0]
IndexError: list index out of range
#16 0x00007f1a3f584cc2 in filter::config::TypeDetection::impl_detectTypeFlatAndDeep (this=0x299e710, rDescriptor=..., lFlatTypes=std::__debug::list, bAllowDeep=1 '\001', rUsedDetectors=..., rLastChance="") at /master/filter/source/config/cache/typedetection.cxx:836
#17 0x00007f1a3f5822f4 in filter::config::TypeDetection::queryTypeByDescriptor (this=0x299e710, lDescriptor=uno::Sequence of length 7 = {...}, bAllowDeep=1 '\001') at /master/filter/source/config/cache/typedetection.cxx:296
#18 0x00007f1a47fb4fee in framework::LoadEnv::impl_detectTypeAndFilter (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:796
#19 0x00007f1a47fb3782 in framework::LoadEnv::startLoading (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:382
#20 0x00007f1a47f38754 in framework::LoadDispatcher::impl_dispatch (this=0x2d22bf0, rURL=..., lArguments=uno::Sequence of length 3 = {...}, xListener=empty uno::Reference) at /master/framework/source/dispatch/loaddispatcher.cxx:119


second open is then to copy the file to a temp-file in SfxMedium:

#0  open64 () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f1a5cb64740 in osl_openFilePath (cpFilePath=0x7fff78459810 "/Documents/RGBA PNG.odt", pHandle=0x7fff78458698, uFlags=41) at /master/sal/osl/unx/file.cxx:914
...
#14 0x00007f1a5919f38e in ucbhelper::Content::transferContent (this=0x7fff7845cb30, rSourceContent=..., eOperation=ucbhelper::InsertOperation_COPY, rTitle="lu10khfm.tmp", nNameClashAction=1, rMimeType="application/vnd.oasis.opendocument.text", bMajorVersion=false, rVersionComment="", pResultURL=0x0) at /master/ucbhelper/source/client/content.cxx:1030
#15 0x00007f1a5b066d85 in SfxMedium::CreateTempFile (this=0x2d87e30, bReplace=0 '\000') at /master/sfx2/source/doc/docfile.cxx:3343
#16 0x00007f1a5b05c224 in SfxMedium::GetStorage (this=0x2d87e30, bCreateTempIfNo=1 '\001') at /master/sfx2/source/doc/docfile.cxx:1254
#17 0x00007f1a5b0d02f0 in SfxObjectShell::DoLoad (this=0x2873360, pMed=0x2d87e30) at /master/sfx2/source/doc/objstor.cxx:637
#18 0x00007f1a5b115f1a in SfxBaseModel::load (this=0x3052940, seqArguments=uno::Sequence of length 14 = {...}) at /master/sfx2/source/doc/sfxbasemodel.cxx:1878
#19 0x00007f1a5b17b7fb in SfxFrameLoader_Impl::load (this=0x2f11520, rArgs=uno::Sequence of length 13 = {...}, _rTargetFrame=uno::Reference to {
  <com::sun::star::lang::XComponent> = {
    <com::sun::star::uno::XInterface> = {
      _vptr.XInterface = 0x7f1a48507430
    }, <No data fields>}, <No data fields>}) at /master/sfx2/source/view/frmload.cxx:598
#20 0x00007f1a47fb71eb in framework::LoadEnv::impl_loadContent (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:1151
#21 0x00007f1a47fb37c7 in framework::LoadEnv::startLoading (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:399
#22 0x00007f1a47f38754 in framework::LoadDispatcher::impl_dispatch (this=0x2d22bf0, rURL=..., lArguments=uno::Sequence of length 3 = {...}, xListener=empty uno::Reference) at /master/framework/source/dispatch/loaddispatcher.cxx:119


... no idea what to do about it, other than perhaps to somehow use the
Media Descriptor stream to create the temp file?

i wonder why that used to work in older versions then?

(In reply to comment #7)

> trying it with a local file i get first open from type detection
> filling the XInputStream in the Media Descriptor:

> second open is then to copy the file to a temp-file in SfxMedium:

> ... no idea what to do about it, other than perhaps to somehow use the
> Media Descriptor stream to create the temp file?

Or close the Media Descriptor stream before creating the temp file? Or think again why we need a lock?

> i wonder why that used to work in older versions then?

Here's the difference I see from the strace: In older versions, the first opened file is not read from before opening the second file. Possibly the lock that is taken is "lazy", as in it is gotten only when actually reading/writing data from/to the file?

Actually, the first opened file is *never* read from. So it seems the "XInputStream in the Media Descriptor" is never used in older versions. So my guess is that something changed in type detection, or maybe XInputStream is less lazy?

First open (presumed to be type detection)

27360 access("/path/to/filename.odt", F_OK) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 open("/path/to/filename.odt", O_RDWR|O_EXCL) = 33
27360 fstat(33, {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 fcntl(33, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0

Then a weird dance is done where the lockfile is created as a temporary file and then copied to the actual lockfile (why not write directly to the lockfile?)

27360 open("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp", O_RDWR|O_EXCL) = 36
27360 fstat(36, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
27360 fcntl(36, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
27360 pread(36, "", 4096, 0)            = 0
27360 pwrite(36, ",master,camp.domain.gestman.lu,1"..., 90, 0) = 90
27360 close(36)                         = 0
27360 open("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp", O_RDWR|O_EXCL) = 36
27360 fstat(36, {st_mode=S_IFREG|0600, st_size=90, ...}) = 0
27360 fcntl(36, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
27360 open("/path/to/.~lock.filename.odt#", O_RDONLY|O_EXCL) = -1 ENOENT (No such file or directory)
27360 open("/path/to/.~lock.filename.odt#", O_RDWR|O_CREAT|O_EXCL, 0666) = 63
27360 fstat(63, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
27360 pread(36, ",master,camp.domain.gestman.lu,1"..., 32768, 0) = 90
27360 close(36)                         = 0
27360 pread(63, "", 4096, 0)            = 0
27360 pwrite(63, ",master,camp.domain.gestman.lu,1"..., 90, 0) = 90
27360 close(63)                         = 0
27360 lstat("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp", {st_mode=S_IFREG|0600, st_size=90, ...}) = 0
27360 unlink("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp") = 0

Second open, and read/write:

27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 access("/tmp/lu1d2lc5.tmp", F_OK) = 0
27360 lstat("/tmp/lu1d2lc5.tmp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 open("/path/to/filename.odt", O_RDONLY) = 36
27360 fstat(36, {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 open("/tmp/lu1d2lc5.tmp/lu1d2lh2.tmp", O_WRONLY|O_CREAT, 0100600) = 63
27360 pread(36, "PK\3\4\24\0\0\10\0\0zC+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 32767, 0) = 32767
27360 write(63, "PK\3\4\24\0\0\10\0\0zC+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 32767) = 32767
27360 pread(36, "\0245\356v\347:|<\242\314\304\343\243(+\3235K~\313\265\226}\342\245\240yN\245\323}\320"..., 9621, 32767) = 9621
27360 write(63, "\0245\356v\347:|<\242\314\304\343\243(+\3235K~\313\265\226}\342\245\240yN\245\323}\320"..., 9621) = 9621
27360 close(36)                         = 0
27360 close(63)                         = 0

I just discovered that I get the problem only on *some* files. Here's what an strace looks on a file that works in 4.0:

27598 access("/path/to/filename.odt", F_OK) = 0
27598 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=2914
27598 access("/path/to/filename.odt", F_OK) = 0
27598 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=2914
27598 open("/path/to/filename.odt", O_RDONLY|O_EXCL) = 67
27598 fstat(67, {st_mode=S_IFREG|0600, st_size=29142, ...}) = 0
27598 pread(67, "PK\3\4\24\0\0\10\0\0!K+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 4096, 0) = 4096
27598 pread(67, " \221\201@\215\tL\312\204t\203\34\272NK\3053\226\363Q9\301\241\355\342\307`\275\323\203\242<"..., 4096, 24576) = 4096
27598 pread(67, "\0\0Configurations2/toolbar/PK\1\2\24\0"..., 4096, 28672) = 470
27598 pread(67, " \221\201@\215\tL\312\204t\203\34\272NK\3053\226\363Q9\301\241\355\342\307`\275\323\203\242<"..., 4096, 24576) = 4096
27598 pread(67, "\0\0Configurations2/toolbar/PK\1\2\24\0"..., 4096, 28672) = 470
27598 pread(67, " \221\201@\215\tL\312\204t\203\34\272NK\3053\226\363Q9\301\241\355\342\307`\275\323\203\242<"..., 4096, 24576) = 4096
27598 time(NULL)                        = 1358397004
27598 pread(67, "PK\3\4\24\0\0\10\0\0!K+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 4096, 0) = 4096
27598 close(67)                         = 0



Here, the "type detection" file open is *closed* before proceeding to the "copy to temporary file", thus freeing the lock.

(In reply to comment #0)
> LibreOffice then reads from and writes to the file from the first (R/W) fd:
> 
> pread(65,
> "WQ'\212\n\305\3D\250n\351\31\341\22\221\35\252\323\374\236\351\232\223Nt\275
> 2\232\6\352\304\352"..., 4096, 4096) = 4096
> 8550  pwrite(65,
> "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 8192, 0)
> = 8192
> 8550  pread(65,  <unfinished ...>
> 8550  pwrite(65,
> "\253\334\7aQ\230\30\30H\5v\1\261L\351\243lr\22O6\2716d\375\240\t\232\225\302
> EP"..., 8192, 8192) = 8192
> 8550  pread(65,
> "\212E\323\t\245\210A\306\316P\333\202\5\v\304\32X[\374zk\25\337\355\f\325R9\
> 376(\n>"..., 8192, 16384) = 8192
> 8550  pwrite(65,
> "\212E\323\t\245\210A\306\316P\333\202\5\v\304\32X[\374zk\25\337\355\f\325R9\
> 376(\n>"..., 8192, 16384) = 8192
> 8550  pread(65, "y!
> \270\212E*\224(\245\352\216\31\366?\324\315t\240\222\333\253D\335\322\342\265
> K\32\215R\232"..., 8192, 24576) = 8192
> 8550  pwrite(65, "y!
> \270\212E*\224(\245\352\216\31\366?\324\315t\240\222\333\253D\335\322\342\265
> K\32\215R\232"..., 8192, 24576) = 8192
> 8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"...,
> 8192, 32768) = 189
> 8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"...,
> 4096, 32768) = 189

It seems to be essentially copying the file to itself (!). So possibly there is some mixup somewhere between "temporary file" and "original file".

Note that this is annoying as behaviour, because it updates the file's "last modified" timestamp when merely opening the file (no change, no save).

Also, it seems to be linked to this bug. When opening the file succeeds, its "last modified" timestamps is *NOT* changed.

(In reply to comment #8)
> (In reply to comment #7)
> 
> > trying it with a local file i get first open from type detection
> > filling the XInputStream in the Media Descriptor:
> 
> > second open is then to copy the file to a temp-file in SfxMedium:
> 
> > ... no idea what to do about it, other than perhaps to somehow use the
> > Media Descriptor stream to create the temp file?
> 
> Or close the Media Descriptor stream before creating the temp file? Or think
> again why we need a lock?

this whole SfxMedium stuff is rather complex and i don't understand
much of it anyway...

> > i wonder why that used to work in older versions then?
> 
> Here's the difference I see from the strace: In older versions, the first
> opened file is not read from before opening the second file. Possibly the
> lock that is taken is "lazy", as in it is gotten only when actually
> reading/writing data from/to the file?
> 
> Actually, the first opened file is *never* read from. So it seems the
> "XInputStream in the Media Descriptor" is never used in older versions. So
> my guess is that something changed in type detection, or maybe XInputStream
> is less lazy?

interesting. what happens if you revert 0c2206081de38a41597aadfb2255540d6308be63 ?

(In reply to comment #11)
> (In reply to comment #8)
>> (In reply to comment #7)

>>> i wonder why that used to work in older versions then?

>> Here's the difference I see from the strace: In older versions, (...)
>> the first opened file is *never* read from. So it seems the
>> "XInputStream in the Media Descriptor" is never used in older versions.

> interesting. what happens if you revert
> 0c2206081de38a41597aadfb2255540d6308be63 ?

This bug disappears.

(In reply to comment #12)
> (In reply to comment #11)
> > interesting. what happens if you revert
> > 0c2206081de38a41597aadfb2255540d6308be63 ?
> 
> This bug disappears.

so we can choose between locking problems on Windows and locking problems on Linux... life is awesome :)

Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0799130b0ba954715d00feb93cef83dd48e29889

fdo#59022: revert "SfxMedium::GetOutputStream(): re-use existing XStream"



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

so i've decided to revert the SfxMedium change for now;
the unit test that didn't work on Windows used different filter flags
than the actual LO.

this should hopefully fix things according to comment #12.

Awaiting review for backport to 4.0.1: https://gerrit.libreoffice.org/#/c/1952/

On Fri, Feb 01, 2013 at 07:11:06AM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=59022

> Lionel Elie Mamane <lionel@mamane.lu> changed:

>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jmadero.dev@gmail.com

Since you mentioned you were looking for Samba-related bugs, I bring
this one to your attention. Fixed in master (4.1).

Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6523f78456c9f78fb842b7215eb84a96f4e92472&h=libreoffice-4-0

fdo#59022: revert "SfxMedium::GetOutputStream(): re-use existing XStream"


It will be available in LibreOffice 4.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

*** Bug 61267 has been marked as a duplicate of this bug. ***