Bug 39950

Summary: Libreoffice Base crashes when trying to drag and drop or copy/paste controls in report builder.
Product: LibreOffice Reporter: Yifan Jiang <yfjiang>
Component: ExtensionsAssignee: Caolán McNamara <caolanm>
Status: VERIFIED FIXED QA Contact:
Severity: critical    
Priority: medium CC: caolanm, lionel, l.lunak, osc, totoiiie4ka
Version: 3.4.2 RC2Keywords: regression
Hardware: All   
OS: All   
Whiteboard: target:3.4.5 target:3.5
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 35673    
Attachments: test sample
crash stack
CopyPaste Field within report crash LO 342
valgrind log
quick demo hack, force old partial clone
demo
backtrace and other gdb info *after* Caolán's fix

Description Yifan Jiang 2011-08-08 21:26:03 UTC
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
Comment 1 Yifan Jiang 2011-08-08 21:26:30 UTC
Created attachment 50056 [details]
crash stack
Comment 2 Alex Thurgood 2011-08-23 05:14:41 UTC
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
Comment 3 Alex Thurgood 2011-08-23 05:19:16 UTC
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
Comment 4 Alex Thurgood 2011-08-23 05:19:58 UTC
Created attachment 50484 [details]
CopyPaste Field within report crash LO 342
Comment 5 Alex Thurgood 2011-08-23 05:25:12 UTC
Also confirming that this does not happen with LO 3.3.4.


Alex
Comment 6 Alex Thurgood 2011-08-23 05:26:03 UTC
This could be the same bug as 40228. Setting that one as dup of this.

Alex
Comment 7 Alex Thurgood 2011-08-23 05:28:33 UTC
*** Bug 40228 has been marked as a duplicate of this bug. ***
Comment 8 Alex Thurgood 2011-08-23 05:30:05 UTC
Setting regression keyword
Comment 9 Yifan Jiang 2011-09-05 02:44:26 UTC
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.
Comment 10 Alex Thurgood 2011-11-09 06:15:40 UTC
*** Bug 42714 has been marked as a duplicate of this bug. ***
Comment 11 Alex Thurgood 2011-11-09 06:17:44 UTC
I would like to set this as a blocker for 3.5 also.


Alex
Comment 12 Lionel Elie Mamane 2011-11-18 13:12:10 UTC
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
Comment 13 Lionel Elie Mamane 2011-11-18 14:03:32 UTC
(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...
Comment 14 Petr Mladek 2011-11-21 10:02:12 UTC
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.
Comment 15 Lionel Elie Mamane 2011-11-21 10:26:23 UTC
(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.
Comment 16 Caolán McNamara 2011-11-23 08:50:59 UTC
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
Comment 17 Lionel Elie Mamane 2011-11-23 09:31:25 UTC
(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.
Comment 18 Lionel Elie Mamane 2011-11-23 09:34:58 UTC
(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.
Comment 19 Lionel Elie Mamane 2011-11-23 09:52:07 UTC
(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.
Comment 20 Lionel Elie Mamane 2011-11-23 11:42:36 UTC
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.
Comment 21 Lionel Elie Mamane 2011-11-23 12:57:55 UTC
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...
Comment 22 Caolán McNamara 2011-11-24 15:00:39 UTC
Created attachment 53841 [details]
valgrind log

export G_SLICE=always-malloc
valgrind --error-limit=no --num-callers=50 ./soffice.bin ~/Documents/demo.odb
Comment 23 Caolán McNamara 2011-11-24 15:20:08 UTC
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.
Comment 24 Caolán McNamara 2011-11-25 08:55:38 UTC
Created attachment 53851 [details] [review]
quick demo hack, force old partial clone

does this make it "go away"
Comment 25 Caolán McNamara 2011-11-25 12:20:18 UTC
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.
Comment 26 Lionel Elie Mamane 2011-11-28 05:02:35 UTC
(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.
Comment 27 Lionel Elie Mamane 2011-11-28 05:10:12 UTC
(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.
Comment 28 Lionel Elie Mamane 2011-11-28 05:46:49 UTC
(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?
Comment 29 Caolán McNamara 2011-11-28 07:23:28 UTC
"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 :-)
Comment 30 Caolán McNamara 2011-11-28 07:24:16 UTC
Created attachment 53904 [details] [review]
demo
Comment 31 Lionel Elie Mamane 2011-11-28 08:27:54 UTC
(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.
Comment 32 Lionel Elie Mamane 2011-11-29 13:15:06 UTC
The fix has been committed to libreoffice-3-4 and will be part of release 3.4.5
Comment 33 Lionel Elie Mamane 2011-12-07 06:36:31 UTC
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".
Comment 34 Lionel Elie Mamane 2011-12-07 06:37:07 UTC
Created attachment 54182 [details]
backtrace and other gdb info *after* Caolán's fix
Comment 35 Lionel Elie Mamane 2011-12-07 06:39:59 UTC
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().
Comment 36 Caolán McNamara 2011-12-07 06:41:08 UTC
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 ?
Comment 37 Lionel Elie Mamane 2011-12-07 09:15:47 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.