+++ 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 [details] (from bug 48056) leads to a crash.

Steps to reproduce:
1. Open attachment 59233 [details] 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 <luke@deller.id.au>
AuthorDate: Sun Apr 28 07:06:11 2013 +1000
Commit:     David Tardon <dtardon@redhat.com>
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?