Created attachment 145854 [details]
call stack as reported by Visual Studio

Created attachment 145855 [details]
Crash as seen in VS2017

Created attachment 145856 [details]
"after" database after the crash

It crashes too, if the footer section is active while insert page number in footer.

Confirmed with Ubuntu 18.04 and LibreOffice 6.2Alpha0
Crash report included.

It was OK in Version: 5.4.7.2 (x64)
Build ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU threads: 8; OS: Windows 6.19; UI render: default; 
Locale: en-US (en_US); Calc: CL

(In reply to Regina Henschel from comment #6)
> It was OK in Version: 5.4.7.2 (x64)
> Build ID: c838ef25c16710f8838b1faec480ebba495259d0
> CPU threads: 8; OS: Windows 6.19; UI render: default; 
> Locale: en-US (en_US); Calc: CL

Also using Ubuntu 18.04 - it works as expected in 6.0.7 and crashes in 6.1.2

Created attachment 145860 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.

It may be due to https://cgit.freedesktop.org/libreoffice/core/commit/?id=f2bd68c33c13b94cf844227d04a7eba9fe3723f8

I submitted this patch to review:
https://gerrit.libreoffice.org/#/c/62082/1

See comments of this one.
In brief, perhaps my previous patch on tdf#120152 was wrong but I had no feedback about it.

Hi Julien, with that patch I can insert a page number field. But I think, there is still something wrong. If a try to insert a shape, I get a crash with the unpatched version and an assertion with your patch. Tested on master.
Assertion failed!
Program: ..\core\instdir\program\rptuilo.dll
File: .. /Reference.h
Line:420

Expression: _pInterface != NULL

(In reply to Regina Henschel from comment #10)
> Hi Julien, with that patch I can insert a page number field. But I think,
> there is still something wrong. If a try to insert a shape, I get a crash
> with the unpatched version and an assertion with your patch. Tested on
> master.
> Assertion failed!
> Program: ..\core\instdir\program\rptuilo.dll
> File: .. /Reference.h
> Line:420
> 
> Expression: _pInterface != NULL

Indeed, I could reproduce the assert with master sources + patch.

I could also reproduce this with LO Debian package 6.1.3.1 so before all of my patches were there since none has been included in 6.1 branch for the moment.

Crash report: http://crashreport.libreoffice.org/stats/signature/rptui::OReportController::createControl(com::sun::star::uno::Sequence%3Ccom::sun::star::beans::PropertyValue%3E%20const%20&,com::sun::star::uno::Reference%3Ccom::sun::star::report::XSection%3E%20const%20&,rtl::OUString%20const%20&,unsigned%20short)

Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=4b4942224b550235da228655677b5c068a053254

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-04-16 22:34:50 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-05-25 12:31:32 +0200
commit 4b4942224b550235da228655677b5c068a053254 (patch)
tree a660a04a1f7a3eee910da780ece271d68942201d
parent f8edef392245c292398a80f6a858ca19f32df9c3 (diff)
SOSAW080: Derive SdrObjGroup from SdrObjList

Bisected with: bibisect-linux64-6.2

Adding Cc: to Armin Le Grand

Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

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

tdf#120728: retrieve label page

It will be available in 6.2.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.

Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/f88b95032262c434647475b6af7e33068635b6c4%5E%21

Revert tdf#120782, tdf#120728, tdf#120152, tdf#120151

It will be available in 6.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Should fail again since I reverted my patch.
Indeed, it brought some regression.

Can reproduce

Similar to other stuff:

svxcorelo.dll!SvxDrawPage::CreateShapeByTypeAndInventor(unsigned short nType, SdrInventor nInventor, SdrObject * pObj, SvxDrawPage * mpPage, const rtl::OUString & referer) Line 795 (c:\lo\work04_64\svx\source\unodraw\unopage.cxx:795)
svxcorelo.dll!SdrObject::getUnoShape() Line 2812 (c:\lo\work04_64\svx\source\svdraw\svdobj.cxx:2812)
rptlo.dll!rptui::OObjectBase::getUnoShapeOf(SdrObject & _rSdrObject) Line 462 (c:\lo\work04_64\reportdesign\source\core\sdr\RptObject.cxx:462)
rptlo.dll!rptui::OUnoObject::getUnoShape() Line 896 (c:\lo\work04_64\reportdesign\source\core\sdr\RptObject.cxx:896)
rptuilo.dll!rptui::OReportController::createControl(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & _aArgs, const com::sun::star::uno::Reference<com::sun::star::report::XSection> & _xSection, const rtl::OUString & _sFunction, unsigned short _nObjectId) Line 3167 (c:\lo\work04_64\reportdesign\source\ui\report\ReportController.cxx:3167)

At the SdrObject (a rptui::OUnoObject) no SdrPage is set die to not being added, so

SdrObject::getUnoShape()

uses the static call

SvxDrawPage::CreateShapeByTypeAndInventor

instead of the dynamic one above it. That call does not know the 'ReportDesign' inventor and fails.

One idea is that a factory that does have no possibility to add creators (here: for ReportDesign) is a bad design by itself.

Another one is the usual - debug the old code, check where/when the SDrObject gets added to a SdrPage and see if this can be done early...

In lo5.2 was implicitely inserted in

void correctOverlapping(SdrObject* _pControl,OReportSection& _aReportSection,bool _bInsert)

where _bInsert is defaulted to true. It is not explicitely inserted when called at the end of

void OReportController::createControl(const Sequence< PropertyValue >& _aArgs,const uno::Reference< report::XSection>& _xSection,const OUString& _sFunction,sal_uInt16 _nObjectId)

Thus looks as if inserting to a SdrPage was seen as not so relevant Model-defining action (?) which is bad.
The fix tdf#120674 does not help here due to being specialized for end of interactive creation.
For those SdrObject created in ReportDesign editor there seems to be no well-designed place where to insert the created model objects (probably due to that effect that a SdrPage-ptr was already set in old days without the SdrObject being inserted what was inconsistent).

OTOH the factory (DlgEdFactory, see SdrObject::getUnoShape()) will only do the right thing when getSdrPageFromSdrObject() does something useful. This is not a good design anyways, maybe best solution is to correct that one to get a SdrPage as input parameter. SdrObject::getUnoShape() should probably work without the SdrObject being inserted to a SdrPage already.
That again raises the question: Is SvxDrawPage::CreateShape the right place at all? Should a factory method fo shape creation not better be placed at the SdrModel/XModel? Or the other way around: When being added to the Page, will it ever make  sense to create different objects for different pages in the same model?

But that goes too far - will not move ::CreateShape implementations to model derivations, even when that would make sense.

For now, will take a closer look at maybe giving SdrObject::getUnoShape() a parameter for the SdrPage with the purpose to get an incarnation of such a SdrPage for the only purpose to be able to call the overloaded ::CreateShape or ::CreateShapeByTypeAndInventor at the correct SdrPage derivation...

Hard stuff, analyzed. Still there is a relatively 'simple' solution. Added that and quite some comments. 1st veraion of fix at https://gerrit.libreoffice.org/#/c/62710/
Looks as if that also fixes tdf#120152.
tdf#120674 is not influenced and still needed - that one was about not getting the SdrObjects inserted/initialized.

Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/52bbb04f1e39b2d778275c91f77b6c0714ecd0d0%5E%21

tdf#120728 support SvxShape for SdrShape if not inserted

It will be available in 6.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Re-checked, works well.

Verified in

Version: 6.2.0.0.alpha1+
Build ID: 4326fb3ef3ddd7c6f9d08ba96add4f4736503ceb
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

@Armin, Thanks for fixing this!!

Cherry-picked to 6.1 -> https://gerrit.libreoffice.org/#/c/62738/

Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

https://git.libreoffice.org/core/+/f05a551a6b49916241696481567e32b320c6749b%5E%21

tdf#120728 support SvxShape for SdrShape if not inserted

It will be available in 6.1.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Verified in Version: 6.1.4.0.0+ (x64)
Build ID: 502077fb9a9387a5aac85dabf445c10718309611
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-11-05_13:11:30
Locale: en-US (en_US); Calc: CL

*** Bug 121351 has been marked as a duplicate of this bug. ***

*** Bug 123044 has been marked as a duplicate of this bug. ***