Description: This Bug is quite similar to 126595. Now we face this problem again when trying to open a .doc/.docx file with LibreOffice. When trying to open a document via a WebDAV-request initiated by an Active-X plugin LibreOffice crashes when the servers submits an xml-formatted error. Steps to Reproduce: Fiddler Shows following error: HTTP/1.1 423 Locked Set-Cookie: JSESSIONID-VIS55PS1=B289C6A550497313101E7F99DD9A098A; Path=/vis; HttpOnly Engine: IT Hit WebDAV Server Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: PROPFIND, PROPPATCH, COPY, MOVE, DELETE, MKCOL, LOCK, UNLOCK, PUT, GETLIB, VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, REPORT, UPDATE, CANCELUPLOAD, HEAD, OPTIONS, GET, POST Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control Access-Control-Max-Age: 2147483647 Content-Type: text/xml;charset=UTF-8 Transfer-Encoding: chunked Date: Fri, 08 Nov 2019 07:24:34 GMT Server: Apache 7d <?xml version="1.0" ?><d:error xmlns:d="DAV:"><d:responsedescription>The object is readonly</d:responsedescription></d:error> 0 Actual Results: LibreOffice crash: crashreport.libreoffice.org/stats/crash_details/f7d58850-d50d-4a17-8432-bafc4dd2f9a1 Expected Results: LibreOffice open the document Reproducible: Always User Profile Reset: No Additional Info:
On Win10 with master sources updated today, I made this test. There's a shared directory from Sharepoint with a docx. If I open the file with LO, no crash. If I open the file with Word (to have a lock) then with LO, it asks me if I should open in read-only, make a copy or cancel. I tried the 2 first ones, no crash. Do you reproduce the crash with any file? (For example, if you create a brand new docx containing just "test")
Also do you reproduce this with LO 64 bits? Indeed, crashreport indicates x86
we may have identified the cause of the problem. it is not the lock that causes the crash but probably an empty response for profind lockdiscovery HTTP/1.1 207 Multi-Status Set-Cookie: JSESSIONID-VIS55PS1=B89B49CDF0AA9A7B582F569B6EFD9DAC; Path=/vis; HttpOnly Engine: IT Hit WebDAV Server Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: PROPFIND, PROPPATCH, COPY, MOVE, DELETE, MKCOL, LOCK, UNLOCK, PUT, GETLIB, VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, REPORT, UPDATE, CANCELUPLOAD, HEAD, OPTIONS, GET, POST Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control Access-Control-Max-Age: 2147483647 Content-Type: text/xml;charset=UTF-8 Transfer-Encoding: chunked Date: Thu, 14 Nov 2019 07:38:11 GMT Server: Apache 177 <?xml version="1.0" ?><d:multistatus xmlns:d="DAV:"><d:response><d:href>http://server:8114/webdav/12450/file.doc</d:href><d:propstat><d:status>HTTP/1.1 200 OK</d:status><d:prop><d:lockdiscovery></d:lockdiscovery></d:prop></d:propstat></d:response></d:multistatus> 0 we will investigate this further. maybe it is a problem in our webdav server. but this should not lead to a crash regardless.
On Win10 with master sources updated today, I still can't reproduce this with a Sharepoint share (which uses Webdav). In SfxMedium::LockOrigFileOnDemand, I tried to add some logs and even to throw manually an exception in https://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx?r=9aadd633#1185. Indeed, even when opening the file with Word and trying to open it with LO, there's no complain. When I added the throw, LO indicates file is readonly and proposed to open it in read-only, copy or cancel. I also noticed LO went into the catch but didn't enter block: "if (aContentToLock.getPropertyValue("DAV:lockdiscovery") >>= aLocks)" which contains css::ucb::Lock treatment. Thorsten: taking a look at dev forum, I noticed a comment from you, any idea here? Also, do we still have both Webdav implementations (serf + neon)?
Forgot to tell that, without adding manual exception, I noticed this in console: warn:ucb.ucp.webdav:6156:16376:ucb/source/ucp/webdav-neon/webdavcontent.cxx:3128: resourceTypeForLocks() DAVException - URL: <XXXHIDEURLXXX>, DAV ExceptionCode: 0, HTTP error: 207
A thread a bit old but indicating some diffs between "neon" (by default Webdav mechanism) and "serf" https://lists.freedesktop.org/archives/libreoffice/2015-August/069739.html
Hello Robert, Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ after bug 129519 got fixed? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
it was tested with 6.2.0.4. the error still exists.
Version 6.2.0.4 is from a year ago, it shold be retested with a fresh master daily build.
sorry. this was a typo. test was with 6.4.0.2
I can reproduce the crash using LO 6.4.0.3 and the application in question, VIS. The corresponding crash report can be found here: https://crashreport.libreoffice.org/stats/crash_details/57f50a26-777e-45fb-8dee-3dfdc54cf2cf As Robert said, the propfind result is empty, so this could be the cause. As we can see from the crash lock, this line crashes: css::ucb::Lock aLock = aLocks[0]; Could it be that this statement: if (aContentToLock.getPropertyValue("DAV:lockdiscovery") >>= aLocks) is true, even if there are no locks? I'm not sure about the Any >>= operator. LO obviously expects locks to be there if a resource is locked - but it shouldn't crash if that's not the case, as an empty lockdiscovery result seems to be allowed in general.
Patch submitted to master: https://cgit.freedesktop.org/libreoffice/core/commit/?id=169a10f0e4680814145b668c6320be04038d7a89
Julian Kalinowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/37cb8ac6abfc9bfd44aed1a51f6374ad1e23583a tdf#128662 Fix exception when accessing empty lock list It will be available in 6.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julian Kalinowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4-3": https://git.libreoffice.org/core/commit/a9ed52fca453f14cd38d948eba749248892577e4 tdf#128662 Fix exception when accessing empty lock list It will be available in 6.4.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Robert @luporpi: Could you please test with 6.4.3 released yesterday? The crash is fixed for me.
Hi Julian, it looks like everything is working well with LO 6.4.3. Instead of a crash it show up a dialog where I can choose if I want to open the file protected or as local copy. Bug is fixed in my mind.
Setting to verified based on comment 16. @Julian, thanks for fixing this issue!!