Apache OpenOffice (AOO) Bugzilla – Issue 9518
Opening a docbook <xml) type document multiple times causes OpenOffice.org to crash
Last modified: 2003-04-24 17:14:38 UTC
This error occurs on Windows 2000, Linux RedHat6.2 and Solaris sparc 9 OpenOffice.org 643C using Java 1.4 Install Mobile devices in OpenOffice.org - Chooses setup in the OpenOffice.org installation directory, choose modify select optional components and select mobile device filters, select modify. When finished select complete. Open OpenOffice.org, ensure that the mobile device filters have been installed by selecting File - Save As, select the drop down list of file types, ensure that file types AportisDoc, DocBook, Flat XML, Pocket Word and XHTML are available. Download the Sample docbook document from http://xml.openoffice.org/xmerge/docbook/ (gedit.xml) Open this document using OpenOffice.org, when opening select File Type DocBook (*.xml) After the document has opened, close the document. Again open the document, again using the File Type DocBook (*.xml). --> OpenOffice.org crashes, see attached file
Created attachment 3751 [details] output of error reported when opening docbook example
Aidan: After a suggestion by Daniel Boelzle, I will try this in SRX644p. He thinks that this issue may be resolved then. If not, I will follow it up.
Aidan: This appears to have been fixed in SRX644p. This fix should be incorporated into the next OOo release. I have tested this on Solaris and Win2000, and I cannot reproduce the original error. This are however a lot more debug messages now in the non-product build, so I will try to determine the source of these.
Aidan: This issue no longer occurs. I have tested this in the latest s2 build. This will be included in the next OOo release.
JA: re-prioritized according to new priority guide lines JA->Aidan: what about modifying the status of this issue ?
Joost, if nobody else changes the status, do it yourself, please. From my point of view, the status should be "resolved worksforme".
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details. First step in IssueZilla is unfortunately to set them to verified.
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.
AB: I am re-opening this issue. The current problem is occuring as a result of the SolarMutex not being locked. The document loads fine the first time, and even reloads correctly using the reload button in the file menu. However, if I close this document, and reload it using the recent files menu, OpenOffice crashes. I have talked with DVO and he has requested for this issue to be transferred to him, as there may be a change required in the XMLImporter.
AB->dvo: Reassigning to you.
This is a normal bug, which will be fixed for OOo1.1beta2. We are ready with the code for beta1. I set this task to the correct milestone.
Additional information, provided by Aidan off-line: RefCount==0 Remove unmoeglich with id/Pos:76 svtools/source/items/itempool.cxx line 901 Removing Item not in Pool with id/Pos 44248 Error: SolarMutex not locked and not thread save code in VCL is called from outside of the main thread. I have also obtained the following stack trace: SVL644MI! SfxItemPool::Remove(class SfxPoolItem const &) + 2836 bytes SVL644MI! SfxItemSet::~SfxItemSet(void) + 880 bytes SVL644MI! SfxItemSet::`vector deleting destructor'(unsigned int) + 15 bytes SW644MI! SwXMLItemSetStyleContext_Impl::~SwXMLItemSetStyleContext_Impl(void) + 57 bytes SW644MI! SwXMLItemSetStyleContext_Impl::`scalar deleting destructor'(unsigned int) + 8 bytes TL644MI! SvRefBase::QueryDelete(void) + 49 bytes XO644MI! SvXMLStylesContext_Impl::Clear(void) + 166 bytes XO644MI! SvXMLStylesContext::Clear(void) + 18 bytes XO644MI! SvXMLImport::~SvXMLImport(void) + 1996 bytes SW644MI! SwXMLImport::~SwXMLImport(void) + 282 bytes SW644MI! SwXMLImport::`scalar deleting destructor'(unsigned int) + 8 bytes CPPUHELPER3MSC! cppu::OWeakObject::release(void) + 111 bytes SW644MI! cppu::WeakImplHelper6<class com::sun::star::xml::sax::XExtendedDocumentHandler,class com::sun::star::lang::XServiceInfo,class com::sun::star::lang::XInitialization,class com::sun::star::document::XImporter,class com::sun::star::document::XFilter,class com::sun::star::lang::XUnoTunnel>::release(void) + 10 bytes MSCI_UNO! msci::cppu_unoInterfaceProxy_free(struct _uno_ExtEnvironment *,void *) + 116 bytes CPPU3! cppu::uno_DefaultEnvironment::uno_DefaultEnvironment(class rtl::OUString const &,void *) + 2113 bytes MSCI_UNO! msci::cppu_unoInterfaceProxy_release(struct _uno_Interface *) + 48 bytes
dvo->nn: If you find some time, please look at it.
The SolarMutex wasn't the main problem. The problem was that the SvXMLImport was freed after the document was closed, but tried to access the document's item pool (for the stored item sets). I moved the stuff that accesses the document from the SvXMLImport destructor to the endDocument method. The fix is in the CWS calc06 and will be in 1.1 Beta2. Changed files: xmloff/source/core/xmlimp.cxx 1.68.2.1.30.1 sc/source/filter/xml/xmlimprt.cxx 1.85.92.1 starmath/source/mathml.cxx 1.61.2.3.16.1 (The changes in sc and starmath are to ensure SvXMLImport::endDocument is called)
Reassigning to QA for verification.
JA:
JA: needed to change the status just to change it to verified... JA: verified withing cws_calc06
JA->DBO: there must be something going wrong with jni_uno_bridge at cws integration of srx644m10-s1. Please have a look at the attached screenshot
Created attachment 5709 [details] Screenshot
JA: changed resolution
fixed Manifest file of xsltfilter.jar
please verify.
JA: Daniel fixed this
JA: verified within uno3 cws
JA: verified within master workspace m12