Bug 90351 - CMIS: crashes with "index out of range!" when saving a document
Summary: CMIS: crashes with "index out of range!" when saving a document
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.4.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Andras Timar
URL:
Whiteboard: target:5.1.0
Keywords: haveBacktrace
Depends on:
Blocks:
 
Reported: 2015-03-30 15:31 UTC by Achim Derigs
Modified: 2016-10-25 19:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
bt with debug symbols (11.81 KB, text/plain)
2015-03-30 20:44 UTC, Julien Nabet
Details
a gdb session for ucbhelper::PropertyValueSet::getObject (13.96 KB, text/plain)
2015-03-30 20:55 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Achim Derigs 2015-03-30 15:31:12 UTC
Version: 4.4.1.2
Build ID: Gentoo official package
Locale: en_US

Trying to save a document via CMIS and server type OpenDataSpace results in the following crash:

warn:legacy.osl:2285:1:ucbhelper/source/provider/propertyvalueset.cxx:456: PropertyValueSet - index out of range!
soffice.bin: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() cost [with T = libcmis::Object; typename boost::detail::sp_member_access<T>::type = libcmis::Object*]: Assertion `px != 0' failed.

If you want to reproduce this, I will create an account on one of our servers for you!
Comment 1 Julien Nabet 2015-03-30 18:55:07 UTC
I can give it a try and retrieve a bt if I can reproduce this, so if you've got some time to create an account for me...
Comment 2 Julien Nabet 2015-03-30 20:29:05 UTC
I've received the email about login, could you provide the url?
Comment 3 Julien Nabet 2015-03-30 20:44:31 UTC
Created attachment 114478 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 4 Julien Nabet 2015-03-30 20:51:02 UTC
Cédric/Cao: thought you might be interested in this one. (bt with symbols has been attached)
Comment 5 Julien Nabet 2015-03-30 20:55:01 UTC
Created attachment 114479 [details]
a gdb session for ucbhelper::PropertyValueSet::getObject
Comment 6 Julien Nabet 2015-03-30 21:37:46 UTC
About the warning, the root cause seems the fact that Content::getPropertyValues (see http://opengrok.libreoffice.org/xref/core/ucb/source/ucp/cmis/cmis_content.cxx#564) doesn't manage "CasePreservingURL" case.

With this patch, we don't have the warning but it still crashes
Also, I suppose we should retrieve the value from the server instead of always setting "true". 
diff --git a/ucb/source/ucp/cmis/cmis_content.cxx b/ucb/source/ucp/cmis/cmis_content.cxx
index 1fc045a5..54c2097 100644
--- a/ucb/source/ucp/cmis/cmis_content.cxx
+++ b/ucb/source/ucp/cmis/cmis_content.cxx
@@ -762,6 +762,10 @@ namespace cmis
                 {
                     xRow->appendBoolean( rProp, false );
                 }
+                else if ( rProp.Name == "CasePreservingURL" )
+                {
+                    xRow->appendBoolean( rProp, true );
+                }
                 else if ( rProp.Name == "TargetURL" )
                 {
                     xRow->appendString( rProp, "" );
Comment 7 Julien Nabet 2015-03-31 19:22:11 UTC
Digging on it with gdb, the problem is in
AtomPubSession::createObjectFromEntryDoc (cmis/src/libcmis/atom-session.cxx)
baseType retrieved is empty so cmisObject is empty
so libcmis::DocumentPtr AtomFolder::createDocument (from cmis/src/libcmis/atom-folder.cxx) throws an exception.
Comment 8 Julien Nabet 2015-03-31 20:12:30 UTC
Cédric/Cao: I'm a bit stuck because I don't know if the problem is this:
string baseTypeReq = "//atom:entry[1]//cmis:propertyId[@propertyDefinitionId='cmis:baseTypeId']/cmis:value/text()";

or if we just don't manage a specific answer (BTW, I don't know how to read it) from the server or something else.

Just to be sure, are you still both working on libcmis or should I cc someone else?
Comment 9 Achim Derigs 2015-05-21 12:09:15 UTC
Same behaviour with 4.4.3.2 ...
Comment 10 Julien Nabet 2015-05-21 12:22:30 UTC
Achim: thank you for your feedback. Version must correspond to the earliest version, so I put back the former value.
Comment 11 Andras Timar 2015-07-08 12:29:03 UTC
In src/libcmis/atom-session.cxx, libcmis::ObjectPtr AtomPubSession::createObjectFromEntryDoc( xmlDocPtr doc ), it is checked, whether the atom entry's baseType property is cmis:folder or cmis:document. The problem is that the function was called with an atom entry which did not have baseType property at all, and the function returned an empty cmis object, which triggered an assert later. Trivial fix is to do the same as the code did before commit a684300a, always create something, if not a folder, then a document. This prevents crash.
Comment 12 Commit Notification 2015-07-08 12:31:29 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5c10e8cd0eedefc2dcc905154c4daa142561aef3

tdf#90351 libcmis: prevent crash

It will be available in 5.1.0.

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.
Comment 13 Commit Notification 2015-07-08 12:47:42 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "master":

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

tdf#90351: server response does not always contain cmis:baseTypeId

It will be available in 5.1.0.

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.