Regression with respect to 4.1.0.
In libreoffice-4-1 branch AFTER APPLICATION of https://gerrit.libreoffice.org/6482
(that is, in what will become LibreOffice 4.1.4, *not* LibreOffice 4.1.3) and in master (4.2.0.alpha) on or after:
Author: Lionel Elie Mamane <firstname.lastname@example.org>
Date: Wed Oct 30 05:35:42 2013 +0100
fdo#70674 adapt wizard code to incompatible Date/Time API change
- open attachment 87880 [details]
- in left pane, click on "Forms"
- in upper right pane, click on "Use Wizard to Create Form"
- click on ">>"
- click on next TWO TIMES
- in "arrangement of the main form", choose any other than the default
(that is, columnar or blocks)
The timestamp field has a white background, while all others have a grey background. It should have a grey background.
The immediate cause for this is:
at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method)
at sun.proxy.$Proxy76.execute(Unknown Source)
which is itself caused by
file wizards/com/sun/star/wizards/form/StyleApplier.java, function applyDBControlProperties:
XPropertySet xPropertySet = oTimeStampControl.getControlofGroupShapeByIndex(i);
getControlofGroupShapeByIndex returns null, which is caused by
file wizards/com/sun/star/wizards/document/TimeStampControl.java, function getControlofGroupShapeByIndex
Object oControl = xShapes.getByIndex(_i);
XControlShape xControlShape = UnoRuntime.queryInterface(XControlShape.class, oControl);
up to there it is fine and not null, but then xControlShape.getControl() returns NULL.
xControlShape is a SvxShapeControl, so this ends up in svx/source/unodraw/unoshap2.cxx,
around line 622:
Reference< awt::XControlModel > SAL_CALL SvxShapeControl::getControl()
throw( uno::RuntimeException )
Reference< awt::XControlModel > xModel;
SdrUnoObj* pUnoObj = dynamic_cast< SdrUnoObj * >(mpObj.get());
if( pUnoObj )
xModel = pUnoObj->GetUnoControlModel();
In the problematic call, mpObj.get() is NULL. But it was non-NULL before...
mpObj is a ::tools::WeakReference< SdrObject >
My understanding of "weak reference" is that it is a reference that does not keep
the object from being garbage-collected (through our reference-counting system).
So, a reference to that object must be held somewhere else; if not it will disappear.
My guess is that this is what happens here.
I don't have any clue what other object is supposed to hold that reference;
mpObj is initialised with a FRESH FmFormObj in the constructor of SvxShapeControl
(which is called as such:
SdrObject* pObj = new FmFormObj();
xRet = static_cast<cppu::OWeakObject*>(static_cast<SvxShape_UnoImplHelper*>(new SvxShapeControl(pObj)));
So I don't see a reference to pObj being held anywhere.
The big mystery is that this exact same code worked in LibreOffice 18.104.22.168 and as far as I can see, none of the code I quoted above changed since 22.214.171.124: not the wizards/... java files, and not svx/source/unodraw/unoshap* and not include/svx/unoshape.hxx.
@davido: I remember you worked on lifetime issues of sdrobject stuff recently. Could this be related?
@sbergman: you helped me out of similar cononudrums in the past; maybe you'd have some insight here?
Can confirm this bug. But much better this cosmetical bug than a not-working form-wizard with timestamp-fields.
i think you should be asking the other David about SdrObject lifecycles :)
> In the problematic call, mpObj.get() is NULL. But it was non-NULL before...
> mpObj is a ::tools::WeakReference< SdrObject >
> My understanding of "weak reference" is that it is a reference that does not
> the object from being garbage-collected (through our reference-counting
> So, a reference to that object must be held somewhere else; if not it will
> My guess is that this is what happens here.
> I don't have any clue what other object is supposed to hold that reference;
> mpObj is initialised with a FRESH FmFormObj in the constructor of
> (which is called as such:
> SdrObject* pObj = new FmFormObj();
> xRet =
> return xRet;
> So I don't see a reference to pObj being held anywhere.
There are two parallel class hierarchies: SdrObject and derived classes are internal representations of various drawing objects and SvxShape and derived are respective UNO impls. (all implementing css::drawing::XShape). Because object of either of them can be created first (SdrObject in UI, SvxShape during import), neither of them can own the other. So instead SdrObjects are owned by SdrPage and SvxShapes by some css::drawing::XShapes impl. SdrObjects are created by SdrPage::CreateSdrObject factory method as an extra init. step for SvxShape. SdrObject creates an SvxShape when needed, if it does not have one already, using css::drawing::XCustomShapeEngine impl. (typically EnhancedCustomShapeEngine). There are few more details I do not quite remember...
Created attachment 100234 [details]
On pc Debian x86-64 with master sources updated today, I can still reproduce this.
Except NullPointer stack trace indicated by Lionel, I noticed several other things like:
1) Before NullPointer stack:
warn:legacy.osl:12277:1:unotools/source/config/moduleoptions.cxx:585: unknown factory
2) After it
warn:legacy.osl:12277:1:sw/source/core/layout/anchoredobject.cxx:616: <SwAnchoredObject::GetObjRectWithSpaces> - cache for object rectangle inclusive spaces marked as valid, but it couldn't be. Missing invalidation of cache. Please inform OD.
warn:legacy.osl:12277:1:xmloff/source/forms/propertyexport.cxx:595: OPropertyExport::implConvertAny: unsupported value type!
warn:legacy.osl:12277:1:basic/source/basmgr/basicmanagerrepository.cxx:581: ImplRepository::_disposing: where does this come from?
warn:legacy.osl:12277:1:xmloff/source/forms/elementimport.cxx:426: OElementImport::implImportGenericProperties: unsupported value type!
warn:legacy.osl:12277:1:xmloff/source/forms/elementimport.cxx:443: OElementImport::EndElement: could not set the property "ObjIDinMSO"!
David? This bug is still present in LibreOffice 4.3.1. You assigned it to yourself and you are indeed the person with IMHO the best knowledge to tackle it, since it is at least linked to SdrObject lifecycles.
Just checking it did not fall under your radar. If you have some time, we would appreciate your input / fix a lot. Thanks in advance!
So you fixed it with fdo#87301 :-)