Description: I'm managing my files on an external/cloud device, you might say. I'm using OneDrive. A couple of days ago, I worked on my school project and uploaded it to the cloud. Today (October 28), I returned to it and found that some of my old patterns had changed to just straight objects. I have no idea why this happened or why only some of them were affected. I tried the 'Refresh All' function, but it didn’t help. Now I don’t know if I did something wrong or if the program failed me. Steps to Reproduce: 1.open file 2.done Actual Results: Many of the old patterns changed to objects. Expected Results: Patters unchanged Reproducible: Couldn't Reproduce User Profile Reset: No Additional Info: I remember that a similar thing happened to me a while ago, and back then, partially refreshing the objects helped.
Created attachment 197278 [details] broken odt.
Created attachment 197279 [details] In case the broken file opens normally on your system.
Menu>Tools>Update>Update All shows Math formulas. What do you mean by patterns?, please detail in what page and position the object is, or their number in the navigator. Please paste here the information on Menu/Help/About LibreOffice (There is an icon to copy) Seems there are not correlation between the object number that some object shows and their number in the navigator. As the very same issues as in https://bugs.documentfoundation.org/show_bug.cgi?id=161719 Also, the file has a lot of issue in the validator. But it is in ODF 1.3 version, maybe not all are well interpreted.
On pc Debian x86-64 with master sources updated today, I confirm that some formulas are replaced by 'Object <number>' Mike: I tried to debug and found that "application/vnd.oasis.opendocument.formula" was used in this bt: #1 0x00007fa0224edb11 in configmgr::Access::getByName (this=0x559ff181f440, aName="application/vnd.oasis.opendocument.formula") at configmgr/source/access.cxx:408 #2 0x00007fa0224edc3f in non-virtual thunk to configmgr::Access::getByName(rtl::OUString const&) () at /home/julien/lo/libreoffice/instdir/program/../program/libconfigmgrlo.so #3 0x00007fa0365cb890 in comphelper::MimeConfigurationHelper::GetExplicitlyRegisteredObjClassID (this=0x559ff19a4570, aMediaType="application/vnd.oasis.opendocument.formula") at comphelper/source/misc/mimeconfighelper.cxx:349 #4 0x00007fa0365ce44c in comphelper::MimeConfigurationHelper::GetFactoryNameByMediaType (this=0x559ff19a4570, aMediaType="application/vnd.oasis.opendocument.formula") at comphelper/source/misc/mimeconfighelper.cxx:549 #5 0x00007fa00e0a037f in UNOEmbeddedObjectCreator::createInstanceInitFromEntry (this=0x559ff19a4520, xStorage=uno::Reference to (OStorage *) 0x559fee190348, sEntName="Object 44", aMedDescr=uno::Sequence of length 1 = {...}, lObjArgs=uno::Sequence of length 2 = {...}) at embeddedobj/source/general/xcreator.cxx:163 #6 0x00007fa00e0a0aa4 in non-virtual thunk to UNOEmbeddedObjectCreator::createInstanceInitFromEntry(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at /home/julien/lo/libreoffice/instdir/program/../program/libembobj.so #7 0x00007fa036488b02 in comphelper::EmbeddedObjectContainer::Get_Impl (this=0x559ff0ec7f30, rName="Object 44", xCopy=empty uno::Reference, pBaseURL=0x7fff1f295120) at comphelper/source/container/embeddedobjectcontainer.cxx:347 #8 0x00007fa036488498 in comphelper::EmbeddedObjectContainer::GetEmbeddedObject (this=0x559ff0ec7f30, rName="Object 44", pBaseURL=0x7fff1f295120) at comphelper/source/container/embeddedobjectcontainer.cxx:300 #9 0x00007fa031f29de0 in SvXMLEmbeddedObjectHelper::ImplReadObject (this=0x559ff0ef0a90, rContainerStorageName="", rObjName="Object 44", pTemp=0x0) at svx/source/xml/xmleohlp.cxx:415 #10 0x00007fa031f2a305 in SvXMLEmbeddedObjectHelper::ImplInsertEmbeddedObjectURL (this=0x559ff0ef0a90, rURLStr="./Object 44") at svx/source/xml/xmleohlp.cxx:449 #11 0x00007fa031f2ab39 in SvXMLEmbeddedObjectHelper::resolveEmbeddedObjectURL (this=0x559ff0ef0a90, rURL="./Object 44") at svx/source/xml/xmleohlp.cxx:555 #12 0x00007fa031f2ae1c in non-virtual thunk to SvXMLEmbeddedObjectHelper::resolveEmbeddedObjectURL(rtl::OUString const&) () at /home/julien/lo/libreoffice/instdir/program/libsvxcorelo.so #13 0x00007fa02a6e72bb in SvXMLImport::ResolveEmbeddedObjectURL (this=0x559ff18333f0, rURL="./Object 44", rClassId=u"") at xmloff/source/core/xmlimp.cxx:1381 #14 0x00007fa02ab6246d in (anonymous namespace)::XMLTextFrameContext_Impl::Create (this=0x559ff0f43660) at xmloff/source/text/XMLTextFrameContext.cxx:451 #15 0x00007fa02ab60ea2 in (anonymous namespace)::XMLTextFrameContext_Impl::XMLTextFrameContext_Impl (this=0x559ff0f43660, rImport=..., rAttrList=uno::Reference to (sax_fastparser::FastAttributeList *) 0x7f9fd809bff8, eATyp=com::sun::star::text::TextContentAnchorType::TextContentAnchorType_AS_CHARACTER, nNewType=3, rFrameAttrList=uno::Reference to (sax_fastparser::FastAttributeList *) 0x559ff1a074b8, bMultipleContent=false) at xmloff/source/text/XMLTextFrameContext.cxx:1127 #16 0x00007fa02ab5eec0 in XMLTextFrameContext::createFastChildContext (this=0x559fee3407a0, nElement=329028, xAttrList=uno::Reference to (sax_fastparser::FastAttributeList *) 0x7f9fd809bff8) at xmloff/source/text/XMLTextFrameContext.cxx:1545 Then I noticed this value "MimeTypeClassIDRelations" and expected to find a file containing some mappings like: application/vnd.oasis.opendocument.formula => <application 1> application/vnd.oasis.opendocument.graphics => <application 2> etc. but I found nothing. Any idea?
(In reply to m_a_riosv from comment #3) > Menu>Tools>Update>Update All > shows Math formulas. > ... I gave a try with Menu>Tools>Update>Update All but from page 7, I still see images with "Object 5", "Object 6", etc.
Attachment 197278 [details] only has 12 ObjectN directories (each containing the data for a single formula). The document itself has much more references to different formulas. This means, that there simply isn't required data in the document; it is damaged irreversibly. I remember seeing a similar problem (I don't remember where: in the Bugzilla, or maybe on Ask?). This is of course a very serious, dataloss, problem. The only way to do anything with it would be having a sample *good* document, plus clear steps to get the failure. Unfortunately, having the already damaged document doesn't allow to reproduce and see why did it happen.
(In reply to Mike Kaganski from comment #6) > Attachment 197278 [details] only has 12 ObjectN directories (each containing > the data for a single formula). The document itself has much more references > to different formulas. This means, that there simply isn't required data in > the document; it is damaged irreversibly. > ... Thank you Mike for the quick feedback! I should definitely have compared the number of ObjectN directories. If there are some missing, no need to use gdb to know there'll be some pbs. KK: since it seems an important document, hope you got some backups.
(In reply to Mike Kaganski from comment #6) > Attachment 197278 [details] only has 12 ObjectN directories (each containing > the data for a single formula). The document itself has much more references > to different formulas. This means, that there simply isn't required data in > the document; it is damaged irreversibly. > > I remember seeing a similar problem (I don't remember where: in the > Bugzilla, or maybe on Ask?). This is of course a very serious, dataloss, > problem. The only way to do anything with it would be having a sample *good* > document, plus clear steps to get the failure. Unfortunately, having the > already damaged document doesn't allow to reproduce and see why did it > happen. bug 99225?