https://bugs.freedesktop.org/show_bug.cgi?id=64279
Priority: medium
Bug ID: 64279
CC: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected]
Assignee: [email protected]
Blocks: 58805, 61723
Summary: REPORTBUILDER: Crash when opening report of attachment
fdo#48056
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: [email protected]
Hardware: Other
Status: UNCONFIRMED
Version: 4.1.0.0.alpha0+ Master
Component: Database
Depends on: 58371, 61725, 64150
Product: LibreOffice
+++ This bug was initially created as a clone of Bug #58371 +++
Problem description:
On pc Debian x86-64 with master sources updated 2013-05-04 (commit
630bc850f7e36f75d295fc1d4a3cc56acd6921e7), trying to edit attachment 59233
(from bug 48056) leads to a crash.
Steps to reproduce:
1. Open attachment 59233 in LibreOffice
(take care of calling it something.odb, not e.g. attachment.cgi?=id59233,
due to a yet unreported bug in automatic content type sniffing in master)
2. In the left pane, click on "Reports"
3. In the lower right pane, right-click on "Bericht1"
4. In the pop-up contextual menu, click on "Edit"
Current behavior:
Crash
Expected behavior:
No crash and open the report in design mode
Analysis:
This comes from commit
commit 57082b1243e86694b72c5e4fad013bf207bfe81a
Author: Luke Deller <[email protected]>
AuthorDate: Sun Apr 28 07:06:11 2013 +1000
Commit: David Tardon <[email protected]>
CommitDate: Sun Apr 28 11:52:12 2013 +0000
fdo#60910: discard UNO shape object in SdrObject::SetPage
Reverting this commit fixes the crash. Why? Because during the parsing of the
report document, when processing the end of a <text:p> tag:
- SvXMLImport::endElement calls pContext->EndElement(), that is
rptxml::OXMLFixedContent::EndElement
- which calls rptxml::OXMLReportElementBase::EndElement()
- which adds the corresponding reportdesign::OFixedText is added to its
section
(namely "Gruppenkopf", the group header):
m_pContainer->getSection()->add(m_xComponent.get())
- reportdesign::OSection::add itself adds it to the draw page:
m_xDrawPage->add(xShape)
- SvxDrawPage::add creates the corresponding sdr object, calling
CreateSdrObject( xShape )
- SvxDrawPage::CreateSdrObject, after creation, inserts the object into the
page: mpPage->InsertObject(pObj)
- mpPage is a rptui::OReportPage, its InsertObject member is
SdrObjList::InsertObject,
- which calls rptui::OReportPage::NbcInsertObject
- which calls SdrObjList::NbcInsertObject
- which calls SdrUnoObj::SetPage: pObj->SetPage(pPage)
- we thus end up (after some more virtual function calling its base class
hierarchy fun)
into SdrObject::SetPage
- which this patch changed to setUnoShape(NULL), thereby depriving the
rptui::OUnoObject
from its UNO shape
- continue execution, until back in rptui::OReportPage::NbcInsertObject
- it calls pObj->getUnoShape(), which constructs a new UNO shape
*but* this UNO shape is not referenced anywhere else than in
m_xKeepShapeAlive
(the meat happens in OObjectBase::getUnoShapeOf)
this also gives an error/warning on stderr:
"SvxShape::HasSdrObjectOwnership: have the ownership of an object which I
don't know!"
- rptui::OReportPage::NbcInsertObject ends with a call to
pObjectBase->releaseUnoShape()
which releases the m_xKeepShapeAlive reference, which leads to the UNO shape
being
deleted, which leads to trouble when subsequent code tries to use it.
By contrast, before this patch, the existing UNO shape is preserved, and all
goes "well".
@dtardon, @luke.deller: where is the bug? In the above referenced commit or in
reportdesign code? If the latter, what should change where in reportdesign
code? Simply not call releaseUnoShape? Call some "setXXX" with the new shape?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
