Created attachment 50055 [details] test sample Platform: SLED 11 sp1 i586 Build info: Libreoffice 3.4.2.2 [Steps] 1. Install libreoffice with libobasis3.4-extension-report-builder 2. Open the attached odb file 3. Switch to Reports tab 4. Right click on the "fruit" report and choose to Edit 5. Drag and Drop a random field in the report builder [Problem] Libreoffice crashes immediately [Extra Information] + It is a regression problem against 3.3 + Crash stack and test data attached
Created attachment 50056 [details] crash stack
Hi Yifan, I can not reproduce on Mac OSX with LO 3.4.2. I can not drag and drop the field names onto the report. However, I can double-click and then it is added. No crash. Alex
Additional info : I can however confirm the crash behaviour if one takes a label object already on the form and tries to drag it to another section. A corresponding field could be drag and dropped just fine, but trying the same thing with the label caused the app to crash. Attached crash report. Alex
Created attachment 50484 [details] CopyPaste Field within report crash LO 342
Also confirming that this does not happen with LO 3.3.4. Alex
This could be the same bug as 40228. Setting that one as dup of this. Alex
*** Bug 40228 has been marked as a duplicate of this bug. ***
Setting regression keyword
Thanks Alex for all your confirmation and test. Besides my description, I can also reproduce the problem you found in comment 3 on SLED 11 sp1 i586 with the latest libreoffice 3.4.2 rc build.
*** Bug 42714 has been marked as a duplicate of this bug. ***
I would like to set this as a blocker for 3.5 also. Alex
So, on master the crash happens in SdrHint constructor SdrHint::SdrHint(const SdrObject& rNewObj), at line maRectangle = rNewObj.GetLastBoundRect(); in file svx/source/svdraw/svdmodel.cxx; that's currently line 2133. The immediate reason is that rNewObj has a trashed vtable. In gdb (with the GNU C++ compiler), do "p /a (*(void***)&rNewObj)[0]@10 to see the first ten entries of the vtable and see they don't make sense. I think the pointer &rNewObj has been deleted() or something like that. Going up the call stack, we land in SdrObjList::InsertObject in file svx/source/svdraw/svdpage.cxx line 405: // Hier muss ein anderer Broadcast her! // Repaint ab Objekt Nummer ... (Achtung: GroupObj) if(pObj->GetPage()) { SdrHint aHint(*pObj); So the object with trashed vtable is *pObj. A few lines up, there is, at line 388: NbcInsertObject(pObj, nPos, pReason); Stepping through the code shows that *before* this function call, *pObj's vtable looks good and it is trashed afterwards. That's a virtual function. The actual implemention called is rptui::OReportPage::NbcInsertObject in file reportdesign/source/core/sdr/RptPage.cxx. It ends with these lines: // now that the shape is inserted into its structures, we can allow the OObjectBase // to release the reference to it OObjectBase* pObjectBase = dynamic_cast< OObjectBase* >( pObj ); OSL_ENSURE( pObjectBase, "OReportPage::NbcInsertObject: what is being inserted here?" ); if ( pObjectBase ) pObjectBase->releaseUnoShape(); If one comments out (or skips with gdb) the "pObjectBase->releaseUnoShape()", that particular crash does not happen anymore. If you test it, beware, the vtable gets trashed not during the call to releaseUnoShape, but just after, during the call to the destructor of xShape above. However, I doubt removing that line is the right fix; we need to understand why the assumption in the comment is not true anymore. For what it is worth, even without that pObjectBase->releaseUnoShape(), it just crashes a bit later in rptui::OReportSection::Paste, file reportdesign/source/ui/report/ReportSection.cxx line 295: pNeuObj->SetLogicRect(aRet); call stack: #0 0x000000000123f250 in ?? () #1 0x00007fffd6297e63 in stoc_inspect::ImplIntrospectionAdapter::getPropertyByName (this=0x2230640, Name="Size") at /home/master/src/libreoffice/core/stoc/source/inspect/introspection.cxx:1085 #2 0x00007fffd02463fe in rptui::OXUndoEnvironment::propertyChange (this=0x1c92ec0, _rEvent=...) at /home/master/src/libreoffice/core/reportdesign/source/core/sdr/UndoEnv.cxx:324 #3 0x00007fffda8fb1f4 in cppu::OInterfaceContainerHelper::NotifySingleListener<com::sun::star::beans::XPropertyChangeListener, com::sun::star::beans::PropertyChangeEvent>::operator() (this=0x7fffffffa400, listener=...) at /home/master/src/libreoffice/core/solver/unxlngx6/inc/cppuhelper/interfacecontainer.h:271 #4 0x00007fffda8fa639 in cppu::OInterfaceContainerHelper::forEach<com::sun::star::beans::XPropertyChangeListener, cppu::OInterfaceContainerHelper::NotifySingleListener<com::sun::star::beans::XPropertyChangeListener, com::sun::star::beans::PropertyChangeEvent> > (this=0x2219970, func=...) at /home/master/src/libreoffice/core/solver/unxlngx6/inc/cppuhelper/interfacecontainer.h:288 #5 0x00007fffda8f98d0 in cppu::OInterfaceContainerHelper::notifyEach<com::sun::star::beans::XPropertyChangeListener, com::sun::star::beans::PropertyChangeEvent> (this=0x2219970, NotificationMethod=&virtual table offset 32, Event=...) at /home/master/src/libreoffice/core/solver/unxlngx6/inc/cppuhelper/interfacecontainer.h:302 #6 0x00007fffda8f798e in svx::PropertyChangeNotifier::notifyPropertyChange (this=0x220bc28, _eProperty=svx::eShapeSize) at /home/master/src/libreoffice/core/svx/source/unodraw/shapepropertynotifier.cxx:178 #7 0x00007fffda7b7682 in SdrObject::notifyShapePropertyChange (this=0x1ad4300, _eProperty=svx::eShapeSize) at /home/master/src/libreoffice/core/svx/source/svdraw/svdobj.cxx:2865 #8 0x00007fffda7b6d44 in SdrObject::SendUserCall (this=0x1ad4300, eUserCall=SDRUSERCALL_RESIZE, rBoundRect=...) at /home/master/src/libreoffice/core/svx/source/svdraw/svdobj.cxx:2722 #9 0x00007fffda7b2004 in SdrObject::SetLogicRect (this=0x1ad4300, rRect=...) at /home/master/src/libreoffice/core/svx/source/svdraw/svdobj.cxx:1608 #10 0x00007fffcf4287b3 in rptui::OReportSection::Paste (this=0x1d219f8, _aAllreadyCopiedObjects=uno::Sequence of length 1 = {...}, _bForce=true) at /home/master/src/libreoffice/core/reportdesign/source/ui/report/ReportSection.cxx:295 Going up down the call stack to stoc_inspect::ImplIntrospectionAdapter::getPropertyByName in file stoc/source/inspect/introspection.cxx: │1082 Property ImplIntrospectionAdapter::getPropertyByName(const OUString& Name) │1083 throw( RuntimeException ) │1084 { >│1085 return mpAccess->getProperty( Name, PropertyConcept::ALL ); │1086 } Again, the problem is trashed vtable: (gdb) print /a (*(void***)mpAccess)[0]@10 $14 = {0x7500065007000a6, 0x21, 0x7ffff70b4eb8 <main_arena+88>, 0x222f890, 0x20, 0x40, 0x500000001, 0x622b60, 0x647c50, 0x648930} Note for future refrence: (gdb) print Name $15 = "Size" Let's go back to following what happens for the crash being discussed. The call to SdrObjList::InsertObject above is just a few lines up in rptui::OReportSection::Paste: if ( pObject ) { SdrObject* pNeuObj = pObject->Clone(); pNeuObj->SetPage( m_pPage ); pNeuObj->SetModel( m_pModel.get() ); SdrInsertReason aReason(SDRREASON_VIEWCALL); m_pPage->InsertObject(pNeuObj,CONTAINER_APPEND,&aReason); Frankly, my hunch tells me that the problem is in pObject->Clone(), but I was not able to follow what happens there. It is a maze of virtual and non-virtual functions and operator= . Here is the stderr while it is being called: Error: No Service Name given! From File /home/master/src/libreoffice/core/reportdesign/source/core/sdr/ReportDrawPage.cxx at Line 82 Error: ::comphelper::copyProperties: could not copy property 'CustomShapeData' to the destination set (a 'com.sun.star.comp.report.Shape' implementation). Caught an exception of type 'com.sun.star.lang.WrappedTargetException', saying 'non-RuntimeException occurred when accessing an interface type attribute'. From File /home/master/src/libreoffice/core/comphelper/source/property/property.cxx at Line 139 Error: ::comphelper::copyProperties: could not copy property 'CustomShapeEngine' to the destination set (a 'com.sun.star.comp.report.Shape' implementation). Caught an exception of type 'com.sun.star.lang.WrappedTargetException', saying 'non-RuntimeException occurred when accessing an interface type attribute'. From File /home/master/src/libreoffice/core/comphelper/source/property/property.cxx at Line 139 Error: ::comphelper::copyProperties: could not copy property 'CustomShapeGeometry' to the destination set (a 'com.sun.star.comp.report.Shape' implementation). Caught an exception of type 'com.sun.star.lang.WrappedTargetException', saying 'non-RuntimeException occurred when accessing an interface type attribute'. From File /home/master/src/libreoffice/core/comphelper/source/property/property.cxx at Line 139
(In reply to comment #12) > Frankly, my hunch tells me that the problem is in pObject->Clone(), but I was > not able to follow what happens there. It is a maze of virtual and non-virtual > functions and operator= . Here is the stderr while it is being called: > Error: ::comphelper::copyProperties: could not copy property 'CustomShapeData' > to the destination set (a 'com.sun.star.comp.report.Shape' implementation). > Caught an exception of type 'com.sun.star.lang.WrappedTargetException', saying > 'non-RuntimeException occurred when accessing an interface type attribute'. > From File > /home/master/src/libreoffice/core/comphelper/source/property/property.cxx at > Line 139 I followed where that error comes from: SvxShape::_getPropertyValue (file svx/source/unodraw/unoshape.cxx) throws beans::UnknownPropertyException(); Backtrace: #1 0x00007fffda9461f4 in SvxShape::_getPropertyValue (this=0x2288d28, PropertyName="CustomShapeData") at /home/master/src/libreoffice/core/svx/source/unodraw/unoshape.cxx:1846 #2 0x00007fffda946114 in SvxShape::getPropertyValue (this=0x2288d28, PropertyName="CustomShapeData") at /home/master/src/libreoffice/core/svx/source/unodraw/unoshape.cxx:1830 #3 0x00007fffda92a1c0 in SvxShapeControl::getPropertyValue (this=0x2288d20, aPropertyName="CustomShapeData") at /home/master/src/libreoffice/core/svx/source/unodraw/unoshap2.cxx:911 #4 0x00007fffd0a1d67c in reportdesign::OShape::getCustomShapeData (this=0x22894e0) at /home/master/src/libreoffice/core/reportdesign/source/core/api/Shape.cxx:490 (...) #11 0x00007fffd0a1beac in reportdesign::OShape::getPropertyValue (this=0x22894e0, PropertyName="CustomShapeData") at /home/master/src/libreoffice/core/reportdesign/source/core/api/Shape.cxx:231 #12 0x00007ffff664338e in comphelper::copyProperties (_rxSource=..., _rxDest=...) at /home/master/src/libreoffice/core/comphelper/source/property/property.cxx:100 (...) Note that the code at comphelper::copyProperties looks like: for (sal_Int32 i=0; i<aSourceProps.getLength(); ++i, ++pSourceProps) { if ( xDestProps->hasPropertyByName(pSourceProps->Name) ) { try { aDestProp = xDestProps->getPropertyByName(pSourceProps->Name); if (0 == (aDestProp.Attributes & PropertyAttribute::READONLY) ) { const Any aSourceValue = _rxSource->getPropertyValue(pSourceProps->Name); So what happens here is that _rxSource->getPropertyValue(pSourceProps->Name) fails while: (gdb) print xSourceProps->hasPropertyByName(pSourceProps->Name) $65 = 1 '\001' xSourceProps is _rxSource->getPropertySetInfo(). That is suspicious...
Hmm, the bug was reported by Novell LO tester. It was confirmed by a person doing the regular bug triage. I do not see any comment from people using this function. It is possible that they are using this functionality another way or there are only very few users. I think that it is fine to keep it in the list of most annoying bugs but it should not block the release => lovering the severity.
(In reply to comment #14) > I do not see any comment from people using this function. Well, people using this function have filed *two* duplicate bugs. So, frankly, I find your remark unfair. > It is possible that they are using this functionality another way or > there are only very few users. That kind of bug is IMO why people on user media (fora, mailing lists, ...) tell newbies not to bother with Base, that it is broken and abandoned by the developers. > I think that it is fine to keep it in the list > of most annoying bugs but it should not block the release => lovering the > severity. I object. That bug is of "brown paper bag" severity. I mean: it is *embarassing* to the project that (this part of) LO cannot *swear*word* copy/paste without crashing the *whole* application, including any open documents in *other* parts (Calc, Writer, ...)! IMHO, the "only few users, so cannot block release" line of thought would be a confirmation of abandonment of Base by the devs.
crash + paste + SdrHint, perhaps this relates to the crash on shutdown on Mac with some odd SdrHint foo in the bt as well. It may be a bad copy ctor/clone post 0527adbab1eca41ae6aeefa6e63c2e02a796c111
(In reply to comment #16) > It may be a bad copy ctor/clone post 0527adbab1eca41ae6aeefa6e63c2e02a796c111 That smells right... I notice that this commit does not touch reportdesign while according to my understanding it is supposed to touch all SdrObject derived objects. Thank you *very* much for the pointer.
(In reply to comment #17) > (In reply to comment #16) >> It may be a bad copy ctor/clone post 0527adbab1eca41ae6aeefa6e63c2e02a796c111 > That smells right... I notice that this commit does not touch reportdesign > while according to my understanding it is supposed to touch all SdrObject > derived objects. Ah no, I was confused by the fact that this is a commit from the "many git repos" era. There is corresponding commit 4afa430c30483767440f61d11e9012e694019157 for reportdesign.
(In reply to comment #18) > (In reply to comment #17) >> (In reply to comment #16) >>> It may be a bad copy ctor/clone post 0527adbab1eca41ae6aeefa6e63c2e02a796c111 >> That smells right... I notice that this commit does not touch reportdesign > Ah no, I was confused by the fact that this is a commit from the "many git > repos" era. There is corresponding commit > 4afa430c30483767440f61d11e9012e694019157 for reportdesign. But it does not touch OReportPage, so we are back on track. I'll try to do the "same changes" to OReportPage and hopefully that will solve this.
Luboš? On Fri Mar 25, you made class SdrPage member SdrPage& operator=(const SdrPage& rSrcPage); non-virtual (file svx/inc/svx/svdpage.hxx), but did not change anything in derived class rptui::OReportPage (files reportdesign/source/core/sdr/RptPage.cxx and reportdesign/inc/RptPage.hxx). We think it might cause this bug. Could you please double-check whether OReportPage needs any adaptation? Thanks in advance.
See https://issues.apache.org/ooo/show_bug.cgi?id=93186#c3 https://issues.apache.org/ooo/show_bug.cgi?id=93186#c4 This might be a consequence of https://issues.apache.org/ooo/show_bug.cgi?id=93212 If yes, then I suppose it is time to fix i#93212 cleanly at last...
Created attachment 53841 [details] valgrind log export G_SLICE=always-malloc valgrind --error-limit=no --num-callers=50 ./soffice.bin ~/Documents/demo.odb
Possible rotten SdrObject retro-fitted with a uno wrapper which might or might not own the SdrObject and may or may not be entitled to destroy it when the uno wrapper goes away. to-do: e.g. breakpoint on TakeSdrObjectOwnership that sort of thing, see who is supposed to own what during RptPage.cxx:217 dance, code suggests that particular XShape doesn't own the SdrObject, maybe, while valgrind trace suggests it does.
Created attachment 53851 [details] quick demo hack, force old partial clone does this make it "go away"
I reckon http://cgit.freedesktop.org/libreoffice/core/commit/?id=9eac8b2d2d5b77e1aa537a8e3756ffbbb10d7e0e will suffice. Please double check, and propose on the list for 3-4 if required, etc.
(In reply to comment #25) > I reckon > http://cgit.freedesktop.org/libreoffice/core/commit/?id=9eac8b2d2d5b77e1aa537a8e3756ffbbb10d7e0e > will suffice. Yes, master does not crash anymore. Debug build says: warn:legacy.osl:7652:1:/home/master/src/libreoffice/core/svx/source/unodraw/unoprov.cxx:899: [CL] unknown SdrObjekt identifier warn:legacy.osl:7652:1:/home/master/src/libreoffice/core/svx/source/unodraw/unoprov.cxx:899: [CL] unknown SdrObjekt identifier warn:legacy.osl:7652:1:/home/master/src/libreoffice/core/svx/source/unodraw/unoprov.cxx:899: [CL] unknown SdrObjekt identifier warn:legacy.osl:7652:1:/home/master/src/libreoffice/core/svx/source/unodraw/unoprov.cxx:899: [CL] unknown SdrObjekt identifier though.
(In reply to comment #26) > Debug build says: > warn:legacy.osl:7652:1:/home/master/src/libreoffice/core/svx/source/unodraw/unoprov.cxx:899: > [CL] unknown SdrObjekt identifier > though. The unknown identifier is "39" in a specific example I'm trying (a textfield). One gets this error only if the Properties pane is open. If one copy/pastes a textfield while properties pane is closed, and then asks for properties of new control (paste *destination*), then one gets these warnings, while one does not get these warnings when asking for the properties of the old control (copy *source*). This suggests to me that something still goes wrong in the clone.
(In reply to comment #27) > (In reply to comment #26) >> Debug build says: >> warn:legacy.osl:7652:1:/home/master/src/libreoffice/core/svx/source/unodraw/unoprov.cxx:899: >> [CL] unknown SdrObjekt identifier > The unknown identifier is "39" in a specific example I'm trying (a textfield). > One gets this error only if the Properties pane is open. If one copy/pastes a > textfield while properties pane is closed, and then asks for properties of new > control (paste *destination*), then one gets these warnings, while one does not > get these warnings when asking for the properties of the old control (copy > *source*). > This suggests to me that something still goes wrong in the clone. The source has identifier 32, namely svx/inc/svx/svdobj.hxx: OBJ_UNO =32, // Universal Network Object im SvDraw-Obj eingepackt The destination's identifier 39 corresponds to reportdesign/inc/RptDef.hxx:#define OBJ_DLG_FORMATTEDFIELD ((sal_uInt16) OBJ_MAXI + 3) Which is a reasonable value, but why the discrepancy? Caolán? Do you have an idea why the identifier is different between the source and the copy?
"why the discrepancy?" Well, firstly I think the discrepancy is really preexisting, e.g. if you insert a new "label" object from scratch and look for its properties, do you also see the assert ? I presume, like me, that you do, and this isn't specific copy-ctor bustage. I think when they are loaded from file, then they are generated as XShapes first or something and the XShape/SvxShape gets set with an id of the "standard" shapes they are implemented in terms of and they then wrapped with RptObjects, and the ids of the SvxShape doesn't get set to that of the owning RptObjects. While, when copied or inserted they start life as RptObjects, and the XShape generated from that gets the "correct" id, but no shape name set so code falls through to the code which asserts. Probably a load of bugs here. i.e. when loaded from file the SvxShape should have the "correct" id of 39 set so that the loaded one should cause the same complaints as the newly inserted and copied ones. They then should probably always have their shape identifier set, whether inserted or loaded so that SvxShape::getShapeType returns early and doesn't continue down to UHashMap::getNameFromId At which point the ids and names would then probably match automatically at copy-ctor time. Here's a hacky patch to silence the assert for the copy case to illustrate, not committed, seeing as it probably shouldn't be necessary and the bustage is elsewhere and not new. I'm not currently working on this aspect if someone wants to chase it down further :-)
Created attachment 53904 [details] demo
(In reply to comment #29) > Well, firstly I think the discrepancy is really preexisting, e.g. if you insert > a new "label" object from scratch and look for its properties, do you also see > the assert ? Yes, that is right. And if I save the report, close it and open again, I don't get the assert anymore. So this is totally unrelated to this bug and its fix.
The fix has been committed to libreoffice-3-4 and will be part of release 3.4.5
My build of libreoffice-3-4 reproduceably crashes (segfault) when opening a report in design mode, with a backtrace that suggests something at least related to the bug fixed here. So, hmm. we've made it worse. (master works well, and is the reason I put this bug to "verified" status) Caolán, could you take a look please? Thanks. Beware of bug 39839 when testing: don't do a full debug build of libreoffice-3-4, Base will be so broken you cannot even get to the point of reprducing, it hangs before that. I've generated the attached backtrace by building only module svx with "debug=T debuglevel=2".
Created attachment 54182 [details] backtrace and other gdb info *after* Caolán's fix
The weird thing in the backtrace is this: #2 0x00007fffda0eeffb in SdrPage::Clone (this=0x1465de0, pNewModel=0xffffffff) at /home/master/src/libreoffice/libreoffice-3.4-nodebug/svx/source/svdraw/svdpage.cxx:1506 1506 SdrPage* pPage2=new SdrPage(*pNewModel); (gdb) up #3 0x00007fffda0ef4bc in SdrPage::SetLwrBorder (this=0x1465de0, nBorder=-1) at /home/master/src/libreoffice/libreoffice-3.4-nodebug/svx/source/svdraw/svdpage.cxx:1634 1634 SetChanged(); From a call to SetChanged, we end up in Clone() and not in SetChanged().
sigh, perhaps it would be nice if the original committer of the code which broke all these things, who is on cc would have a look at the pile of breakages which resulted from his actions ?
Problem disappeared after "make clean && make && make dev-install", so I'll strike the crash off to build system / dependencies bug: something that should have been recompiled was not.