I could replicate this bug on windows 8.1 and OpenOffice 4.2.0. AOO420m1(Build:9800)  -  Rev. 1627435 
- By clicking on Insert >> Frame >> Area  writer crashes and directly switched to recovery mode.
- For further testing I inserted one frame into document and then tried area property on that selected frame. It worked.
- Only when we select area directly whole OpenOffice gets crashed.

I could confirm this problem on Linux x86-64 and Rev. 1648122.

Confirmed on Windows 10 (64-bit) with AOO420m1(Build:9800) - Rev. 1826903.

Program received signal SIGSEGV, Segmentation fault.
XPropertyList::Count (this=0x0) at /openoffice-git/main/svx/source/xoutdev/xtable.cxx:164
164	    if( mbListDirty )
Current language:  auto; currently c++
(gdb) bt
#0  XPropertyList::Count (this=0x0) at /openoffice-git/main/svx/source/xoutdev/xtable.cxx:164
#1  0x00000008063b5cc5 in ColorLB::Fill () at shared_ptr.hpp:339
#2  0x0000000827853118 in SvxAreaTabPage::Construct (this=0x82607e020) at /openoffice-git/main/cui/source/tabpages/tparea.cxx:831
#3  0x000000082785a195 in SvxAreaTabPage::PageCreated (this=0x82607e020, aSet=<value optimized out>) at /openoffice-git/main/cui/source/tabpages/tparea.cxx:2791
#4  0x0000000826344d1e in SwFrmDlg::PageCreated (this=<value optimized out>, nId=<value optimized out>, rPage=@0x82607e020) at /openoffice-git/main/sw/source/ui/frmdlg/frmdlg.cxx:245
#5  0x00000008033dffc6 in SfxTabDialog::ActivatePageHdl (this=0x80d533070, pTabCtrl=0x80d5332f8) at /openoffice-git/main/sfx2/source/dialog/tabdlg.cxx:1479
#6  0x00000008033df7c9 in SfxTabDialog::LinkStubActivatePageHdl (pThis=0x0, pCaller=0x7fffffffc590) at /openoffice-git/main/sfx2/source/dialog/tabdlg.cxx:1383
#7  0x00000008055a2daa in TabControl::SelectTabPage (this=0x80d5332f8, nPageId=10056) at /openoffice-git/main/vcl/source/control/tabctrl.cxx:1899
#8  0x0000000805777fdd in ImplHandleMouseEvent (pWindow=0x800000001, nSVEvent=1, bMouseLeave=0 '\0', nX=<value optimized out>, nY=<value optimized out>, nMsgTime=2293761, nCode=1, nMode=3)
    at /openoffice-git/main/vcl/source/window/winproc.cxx:800
#9  0x000000080577ba17 in ImplHandleSalMouseButtonDown (pWindow=<value optimized out>, pEvent=<value optimized out>) at /openoffice-git/main/vcl/source/window/winproc.cxx:2063
#10 0x000000080da34f3f in GtkSalFrame::signalButton () at gtkframe.hxx:280
#11 0x000000080f762564 in _gtk_marshal_BOOLEAN__BOXED () from /usr/local/lib/libgtk-x11-2.0.so.0
#12 0x000000080ed2de4c in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
#13 0x000000080ed42a05 in g_signal_emitv () from /usr/local/lib/libgobject-2.0.so.0
#14 0x000000080ed439bf in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0
#15 0x000000080ed43d84 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0
#16 0x000000080f893549 in gtk_widget_event () from /usr/local/lib/libgtk-x11-2.0.so.0
#17 0x000000080f7601a2 in gtk_propagate_event () from /usr/local/lib/libgtk-x11-2.0.so.0
#18 0x000000080f75fe78 in gtk_main_do_event () from /usr/local/lib/libgtk-x11-2.0.so.0
#19 0x000000080fcaeaa1 in gdk_screen_get_setting () from /usr/local/lib/libgdk-x11-2.0.so.0
#20 0x000000080efbabc7 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0
#21 0x000000080efbaf53 in g_main_context_pending () from /usr/local/lib/libglib-2.0.so.0
#22 0x000000080efbb004 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0
#23 0x000000080da267ac in GtkXLib::Yield (this=0x800763020, bWait=true, bHandleAllCurrentEvents=<value optimized out>) at /openoffice-git/main/vcl/unx/gtk/app/gtkdata.cxx:874
#24 0x000000080554da4d in ImplYield () at decoview.hxx:91
#25 0x00000008056fe5c8 in Dialog::Execute (this=0x80d533070) at /openoffice-git/main/vcl/source/window/dialog.cxx:701
#26 0x0000000823c96f06 in SwTextShell::ExecInsert () at /openoffice-git/main/sw/source/ui/utlui/numfmtlb.cxx:80
#27 0x000000080338d010 in SfxDispatcher::Call_Impl (this=<value optimized out>, rShell=<value optimized out>, rSlot=@0x8243d8860, rReq=@0x826040920, bRecord=<value optimized out>)
    at /openoffice-git/main/sfx2/source/control/dispatch.cxx:285
#28 0x00000008033900db in SfxDispatcher::PostMsgHandler (this=0x822b85730, pReq=0x826040920) at /openoffice-git/main/sfx2/source/control/dispatch.cxx:1584
#29 0x000000080338d3d5 in SfxDispatcher::LinkStubPostMsgHandler (pThis=0x0, pCaller=0x7fffffffc590) at /openoffice-git/main/sfx2/source/control/dispatch.cxx:1551
#30 0x00000008034b63da in SfxHintPoster::DoEvent_Impl (this=0x822b84800, pPostedHint=<value optimized out>) at /openoffice-git/main/sfx2/source/notify/hintpost.cxx:76
#31 0x000000080577abf3 in ImplHandleUserEvent (pSVEvent=0x82603fc00) at MouseEvent.hpp:33
#32 0x0000000805779336 in ImplWindowFrameProc (pWindow=0x80d5e6590, nEvent=22, pEvent=0x82603fc00) at /openoffice-git/main/vcl/source/window/winproc.cxx:2568
#33 0x000000080dc97713 in SalDisplay::DispatchInternalEvent (this=0x80073ba20) at /openoffice-git/main/vcl/unx/generic/app/saldisp.cxx:2231
#34 0x000000080da26619 in GtkXLib::userEventFn (data=0x800763020) at /openoffice-git/main/vcl/unx/gtk/app/gtkdata.cxx:817
#35 0x000000080efbabc7 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0
#36 0x000000080efbaf53 in g_main_context_pending () from /usr/local/lib/libglib-2.0.so.0
#37 0x000000080efbb004 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0
#38 0x000000080da26774 in GtkXLib::Yield (this=0x800763020, bWait=true, bHandleAllCurrentEvents=<value optimized out>) at /openoffice-git/main/vcl/unx/gtk/app/gtkdata.cxx:869
#39 0x000000080554da4d in ImplYield () at decoview.hxx:91
#40 0x000000080554b01d in Application::Execute () at new:236
#41 0x0000000800e68ac6 in desktop::Desktop::Main (this=0x7fffffffe5b8) at app.cxx:2232
#42 0x0000000805550b87 in ImplSVMain () at /openoffice-git/main/vcl/source/app/svmain.cxx:196
#43 0x0000000805551739 in SVMain () at /openoffice-git/main/vcl/source/app/svmain.cxx:237
#44 0x0000000800eb1b88 in soffice_main () at sofficemain.cxx:45
#45 0x00000000004011b9 in sal_main () at main.c:31
#46 0x0000000000401197 in main (argc=1, argv=0x7fffffffe6a0) at main.c:30

main/cui/source/inc/cuitabarea.hxx

class SvxAreaTabPage : public SvxTabPage
{
....
    XColorListSharedPtr     maColorTab;


(gdb) print maColorTab
$2 = {px = 0x0, pn = {pi_ = 0x0}}


What is XColorListSharedPtr? According to several places:

typedef ::boost::shared_ptr< XColorList > XColorListSharedPtr;

So it looks like the maColorTab shared pointer is used uninitialized.

I also get a crash when editing an inserted frame by double clicking on it and going directly to the Wrap tab.
It must be the first tab clicked otherwise it does not crash.

maColorTab is set by:
    void    SetColorTable( XColorListSharedPtr aColTab ) { maColorTab = aColTab; }

In frame 3, at the bottom of main/cui/source/tabpages/tparea.cxx:

void SvxAreaTabPage::PageCreated (SfxAllItemSet aSet) //add CHINA001
{
...
    if (pColorTabItem)
        SetColorTable(pColorTabItem->GetColorTable());
...
    Construct();
}

so the color table would be initialized before the Construct() that ultimately crashes it, but it isn't.

void SvxAreaTabPage::PageCreated (SfxAllItemSet aSet) //add CHINA001
{
    SFX_ITEMSET_ARG (&aSet,pColorTabItem,SvxColorTableItem,SID_COLOR_TABLE,sal_False);
...
    if (pColorTabItem)
        SetColorTable(pColorTabItem->GetColorTable());
...
    Construct();
}

What is SFX_ITEMSET_ARG?

sfx2/inc/sfx2/request.hxx:
#define SFX_ITEMSET_ARG(pArgs, pItem, ItemType, nSlotId, bDeep) \
    const ItemType *pItem = (const ItemType*) \
        SfxRequest::GetItem( pArgs, nSlotId, bDeep, TYPE(ItemType) )

so apparently the SID_COLOR_TABLE slot ID is absent from the aSet.

Is it not passed to frame 3 from prior frames?

Frame 4 already tried to populate the color table before calling frame 3 ("rPage.PageCreated(aNew);"):

        //UUUU inits for Area and Transparency TabPages
        // The selection attribute lists (XPropertyList derivates, e.g. XColorList for
        // the color table) need to be added as items (e.g. SvxColorTableItem) to make
        // these pages find the needed attributes for fill style suggestions.
        // These are set in preparation to trigger this dialog (FN_FORMAT_FRAME_DLG and
        // FN_DRAW_WRAP_DLG), but could also be directly added from the DrawModel.
        case RID_SVXPAGE_AREA:
        {
            SfxItemSet aNew(*GetInputSetImpl()->GetPool(),
                SID_COLOR_TABLE, SID_BITMAP_LIST,
                SID_OFFER_IMPORT, SID_OFFER_IMPORT, 0, 0);

            aNew.Put(m_rSet);

            // add flag for direct graphic content selection
            aNew.Put(SfxBoolItem(SID_OFFER_IMPORT, true));

            rPage.PageCreated(aNew);
        }

Maybe this branch is interesting?

https://github.com/apache/openoffice/tree/alg_writerframes

It is only on Github, not in our SVN.

I managed to reproduce this unintentionally while playing with our unit tests, so it is quite a common bug. Let's revisit it.

With comments in some of the related files now translated to English, hopefully we can build a better picture of what's going on.




Thread 1 received signal SIGSEGV, Segmentation fault.
XPropertyList::Count (this=0x0) at source/xoutdev/xtable.cxx:164
164	    if( mbListDirty )
(gdb) bt
#0  XPropertyList::Count() const (this=0x0) at source/xoutdev/xtable.cxx:164

Proximally, XPropertyList::Count() is called with a NULL "this". In the "if" statement above, it attempts to access this->mbListDirty, resulting in a SIGSEGV.

------------------------------------------------

#1  0x00000008032d6770 in ColorLB::Fill(boost::shared_ptr<XColorList>) (this=0x80f01b6c8, aColorTab=...) at source/dialog/dlgctrl.cxx:1314

void ColorLB::Fill( const XColorListSharedPtr aColorTab )
{
    long nCount = aColorTab->Count();


The reason frame #0 got a NULL this is because the ColorLB::Fill() method in this frame got passed a NULL "XColorListSharedPtr aColorTab" by its caller, and called Count() on it.

So far, these methods seem innocent: they tried to do the right thing, on invalid data they were passed from further upstream. The next 6 frames deal with tab pages, tab dialogs and tab controls, and the bug is probably there somewhere.

------------------------------------------------

#2  0x000000080ef3b390 in SvxAreaTabPage::Construct() (this=0x80f01b020) at source/tabpages/tparea.cxx:831

main/cui/source/tabpages/tparea.cxx:

void SvxAreaTabPage::Construct()
{
    // fill colortables / lists
    aLbColor.Fill( maColorTab );
    aLbHatchBckgrdColor.Fill ( maColorTab );
                
    aLbGradient.Fill( maGradientList );
    aLbHatching.Fill( maHatchingList );
    aLbBitmap.Fill( maBitmapList );
}

However
(gdb) print maColorTab
$1 = {px = 0x0, pn = {pi_ = 0x0}}

It is here that the invalid maColorTab began from. But how did it become invalid? As I previously noted:

main/cui/source/inc/cuitabarea.hxx
class SvxAreaTabPage : public SvxTabPage
{
....
    XColorListSharedPtr     maColorTab;
....
}

typedef ::boost::shared_ptr< XColorList > XColorListSharedPtr;

and to become invalid, it was either never written to, or overwritten by an invalid value. The places it is written to include:
1.  void    SetColorTable( XColorListSharedPtr aColTab ) {
        maColorTab = aColTab;
    }
which is also called from SvxAreaTabPage::PageCreated() in frame #4.
2. In the constructor:
    maColorTab(),
which probably sets the default NULL value.
3. In SvxAreaTabPage::ActivatePage():
    if( *pnColorTableState & CT_CHANGED )
       maColorTab = ( (SvxAreaTabDialog*) DLGWIN )->GetNewColorTable();
4. Through memory corruption, via any pointer anywhere in the code. If so, it will be extremely difficult to fix.

Possibilities 1-3 can be tested with debugger breakpoints.

It doesn't seem very useful to go into stack frames further upstream, given that the bad value in maColorTab was already set. Let's rather find how and why it arrived at its bad value.

------------------------------------------------

#3  0x000000080ef4239b in SvxAreaTabPage::PageCreated(SfxAllItemSet) (this=0x80f01b020, aSet=...) at source/tabpages/tparea.cxx:2791
#4  0x000000080eb786a1 in SwFrmDlg::PageCreated(unsigned short, SfxTabPage&) (this=0x80ada7860, nId=<optimized out>, rPage=...) at source/ui/frmdlg/frmdlg.cxx:245
#5  0x0000000801468a05 in SfxTabDialog::ActivatePageHdl(TabControl*) (this=0x80ada7860, pTabCtrl=0x80ada7ae8) at source/dialog/tabdlg.cxx:1479
#6  0x0000000801467a28 in SfxTabDialog::LinkStubActivatePageHdl(void*, void*) (pThis=0x80ada7860, pCaller=0x80ada7ae8) at source/dialog/tabdlg.cxx:1383
#7  0x0000000802c17f2f in TabControl::SelectTabPage(unsigned short) (this=0x80ada7ae8, nPageId=10056) at source/control/tabctrl.cxx:1899
#8  0x0000000802e4ea1a in ImplHandleMouseEvent(Window*, unsigned short, unsigned char, long, long, unsigned long, unsigned short, unsigned short)
    (pWindow=<optimized out>, nSVEvent=1, bMouseLeave=0 '\000', nX=<optimized out>, nY=<optimized out>, nMsgTime=177799169, nCode=1, nMode=3) at source/window/winproc.cxx:800
#9  0x0000000802e525cb in ImplHandleSalMouseButtonDown(Window*, SalMouseEvent*) (pWindow=0x0, pEvent=<optimized out>) at source/window/winproc.cxx:2063
#10 0x0000000806664afd in GtkSalFrame::signalButton(_GtkWidget*, _GdkEventButton*, void*) (pEvent=0x80e139ad0, frame=0x80e54b610) at unx/gtk/window/gtkframe.cxx:2678
...

(gdb) break SvxAreaTabPage::SetColorTable
Function "SvxAreaTabPage::SetColorTable" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (SvxAreaTabPage::SetColorTable) pending.
(gdb) break SvxAreaTabPage::SvxAreaTabPage
Function "SvxAreaTabPage::SvxAreaTabPage" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (SvxAreaTabPage::SvxAreaTabPage) pending.
(gdb) break SvxAreaTabPage::ActivatePage
Function "SvxAreaTabPage::ActivatePage" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 3 (SvxAreaTabPage::ActivatePage) pending.
(gdb) c
Thread 1 hit Breakpoint 2, SvxAreaTabPage::SvxAreaTabPage (this=0x80e5f4020, pParent=0x80d4e4ee8, rInAttrs=...) at source/tabpages/tparea.cxx:627
627	:   SvxTabPage			( pParent, CUI_RES( RID_SVXPAGE_AREA ), rInAttrs ),
(gdb) n
...
(gdb) n
670	    maColorTab(),
(gdb) print maColorTab
$1 = {px = 0x7777777777777777, pn = {pi_ = 0x7777777777777777}}
(gdb) n
671	    maGradientList(),
(gdb) print maColorTab
$2 = {px = 0x0, pn = {pi_ = 0x0}}

So the constructor for SvxTabPage runs first, and initializes maColorTab to the "bad" value with the NULL pointer.

(gdb) c
Continuing.

Thread 1 received signal SIGSEGV, Segmentation fault.
XPropertyList::Count (this=0x0) at source/xoutdev/xtable.cxx:164
164	    if( mbListDirty )

It is never changed after the constructor is called, and remains NULL, causing the bug.

Let's first prove that's really the case. Did the breakpoints successfully register?

(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x000000080ee92a02 in SvxAreaTabPage::SetColorTable(boost::shared_ptr<XColorList>) at source/inc/cuitabarea.hxx:309
2       breakpoint     keep y   0x000000080ef80067 in SvxAreaTabPage::SvxAreaTabPage(Window*, SfxItemSet const&) at source/tabpages/tparea.cxx:627
	breakpoint already hit 1 time
3       breakpoint     keep y   0x000000080ef814c9 in SvxAreaTabPage::ActivatePage(SfxItemSet const&) at source/tabpages/tparea.cxx:845

Did SvxAreaTabPage::SetColorTable() get inlined and not trigger? Rebuilding main/cui with maximum debugging and inlining disabled, and repeating this whole debugging session, gets me the same result.

So why isn't SvxAreaTabPage::SetColorTable() called? Frame #3 reached as late as line 2791:

#3  0x000000080ef4239b in SvxAreaTabPage::PageCreated(SfxAllItemSet) (this=0x80f01b020, aSet=...) at source/tabpages/tparea.cxx:2791

which means it got past:

    if (pColorTabItem)
        SetColorTable(pColorTabItem->GetColorTable());

earlier in void SvxAreaTabPage::PageCreated (SfxAllItemSet aSet) //add CHINA001

Let's debug SvxAreaTabPage::PageCreated() itself.

(gdb) 
2765		if (pColorTabItem)
(gdb) print pColorTabItem
$1 = (const SvxColorTableItem *) 0x0

So the pColorTabItem passed to SvxAreaTabPage::PageCreated() was NULL, thus SvxAreaTabPage::SetColorTable() was never called, and remained NULL since the constructor, causing the crash later when we try to access it.

Where does SvxAreaTabPage::PageCreated() get called from?

(gdb) bt
#0  SvxAreaTabPage::PageCreated(SfxAllItemSet) (this=0x80ef47020, aSet=...) at source/tabpages/tparea.cxx:2767
#1  0x000000080e92c6a1 in SwFrmDlg::PageCreated(unsigned short, SfxTabPage&) (this=0x80e3f0060, nId=<optimized out>, rPage=...) at source/ui/frmdlg/frmdlg.cxx:245
#2  0x0000000801468a05 in SfxTabDialog::ActivatePageHdl(TabControl*) (this=0x80e3f0060, pTabCtrl=0x80e3f02e8) at source/dialog/tabdlg.cxx:1479
#3  0x0000000801467a28 in SfxTabDialog::LinkStubActivatePageHdl(void*, void*) (pThis=0x80e3f0060, pCaller=0x80e3f02e8) at source/dialog/tabdlg.cxx:1383
#4  0x0000000802c17f2f in TabControl::SelectTabPage(unsigned short) (this=0x80e3f02e8, nPageId=10056) at source/control/tabctrl.cxx:1899
#5  0x0000000802e4ea1a in ImplHandleMouseEvent(Window*, unsigned short, unsigned char, long, long, unsigned long, unsigned short, unsigned short)
    (pWindow=<optimized out>, nSVEvent=1, bMouseLeave=0 '\000', nX=<optimized out>, nY=<optimized out>, nMsgTime=182648833, nCode=1, nMode=3) at source/window/winproc.cxx:800
...

Comment 13's frame 1 is the same as comment 12's frame 4.

#4  0x000000080eb786a1 in SwFrmDlg::PageCreated(unsigned short, SfxTabPage&) (this=0x80ada7860, nId=<optimized out>, rPage=...) at source/ui/frmdlg/frmdlg.cxx:245

        case RID_SVXPAGE_AREA:
        {
            SfxItemSet aNew(*GetInputSetImpl()->GetPool(),
                SID_COLOR_TABLE, SID_BITMAP_LIST,
                SID_OFFER_IMPORT, SID_OFFER_IMPORT, 0, 0);
            
            aNew.Put(m_rSet);
                        
            // add flag for direct graphic content selection
            aNew.Put(SfxBoolItem(SID_OFFER_IMPORT, true));
                 
            rPage.PageCreated(aNew);
        }
        break;

But the same "Area" tab is also shown for the page and paragraph dialogs, yet doesn't crash. How do the page and paragraph ::PageCreated() methods differ?

For the paragraph, main/sw/source/ui/chrdlg/pardlg.cxx:
        case RID_SVXPAGE_AREA:
        {
            SfxItemSet aNew(*aSet.GetPool(),
                SID_COLOR_TABLE, SID_BITMAP_LIST,
                SID_OFFER_IMPORT, SID_OFFER_IMPORT, 0, 0);

            aNew.Put(*GetInputSetImpl());

            // add flag for direct graphic content selection
            aNew.Put(SfxBoolItem(SID_OFFER_IMPORT, true));

            rPage.PageCreated(aNew);
            break;
        }

For the page, main/sw/source/ui/fmtui/tmpdlg.cxx:
        case RID_SVXPAGE_AREA:
        {
            aSet.Put(GetStyleSheet().GetItemSet());

            // add flag for direct graphic content selection
            aSet.Put(SfxBoolItem(SID_OFFER_IMPORT, true));

            rPage.PageCreated(aSet);
            break;
        }

It seemed to me that SfxItemSet was being constructed wrongly, but the paragraph constructs it the same way. Then I tried passing *GetInputSetImpl() to Put() instead of m_rSet, but it still crashed. Copying the SfxItemSet like the paragraph does didn't help either, even in combonation with the Put() change.

Thus almost certainly the original SfxItemSet returned from GetInputSetImpl() doesn't contain a SID_COLOR_TABLE entry.

How does SID_COLOR_TABLE arrive into SfxItemSet? The comments above page, paragraph and frame RID_SVXPAGE_AREA case statement, state:

//UUUU inits for Area and Transparency TabPages
// The selection attribute lists (XPropertyList derivates, e.g. XColorList for
// the color table) need to be added as items (e.g. SvxColorTableItem) to make
// these pages find the needed attributes for fill style suggestions.
which is followed by this differing text:

Frame:
// These are set in preparation to trigger this dialog (FN_FORMAT_FRAME_DLG and
// FN_DRAW_WRAP_DLG), but could also be directly added from the DrawModel.

Paragraph:
// These are added in SwDocStyleSheet::GetItemSet() for the SFX_STYLE_FAMILY_PARA on 
// demand, but could also be directly added from the DrawModel.

Page:
// These are added in SwDocStyleSheet::GetItemSet() for the SFX_STYLE_FAMILY_PARA on 
// demand, but could also be directly added from the DrawModel.


Seems like FN_FORMAT_FRAME_DLG and FN_DRAW_WRAP_DLG need to be examined.

According to OpenGrok

FN_FORMAT_FRAME_DLG appears in 14 files + many translations. Of the relevant ones, we have:
1. main/sw/source/ui/shells/frmsh.cxx is probably the most relevant, does SID_COLOR_TABLE and:
450                  //UUUU create needed items for XPropertyList entries from the DrawModel so that
451                  // the Area TabPage can access them
2. main/sw/sdi/_frmsh.sdi
        FN_FORMAT_FRAME_DLG   // status(final|play)
 	[
 		ExecMethod = Execute ;
 		StateMethod = GetState ;
 		DisableFlags="SW_DISABLE_ON_PROTECTED_CURSOR";
 	]
3. main/sw/sdi/swriter.sdi
SfxVoidItem FrameDialog FN_FORMAT_FRAME_DLG
Asynchron;
4. main/sw/source/ui/uiview/view2.cxx
void SwView::ExecuteStatusLine(SfxRequest &rReq)
{
    ...
    nId = FN_FORMAT_FRAME_DLG;
    ...
    if( nId )
	GetViewFrame()->GetDispatcher()->Execute(
            static_cast< sal_uInt16 >( nId ), SFX_CALLMODE_SYNCHRON |
                SFX_CALLMODE_RECORD );
5. main/sw/source/ui/utlui/content.cxx
void SwContentTree::EditEntry(SvLBoxEntry* pEntry, sal_uInt8 nMode)
{
    ...
    nSlot = FN_FORMAT_FRAME_DLG;
    ...
    if(nSlot)
        pActiveShell->GetView().GetViewFrame()->
            GetDispatcher()->Execute(nSlot, SFX_CALLMODE_ASYNCHRON);
6. main/sw/source/ui/docvw/edtwin.cxx
void SwEditWin::MouseButtonDown(const MouseEvent& _rMEvt)
{
    ...
    case nsSelectionType::SEL_FRM:
    ...
        GetView().GetViewFrame()->GetBindings().Execute(
           FN_FORMAT_FRAME_DLG, 0, 0, SFX_CALLMODE_RECORD|SFX_CALLMODE_SLOT);


FN_DRAW_WRAP_DLG appears in 15 files + many translations, the relevant ones being:

1. main/sw/source/ui/shells/drwbassh.cxx
long
2. main/sw/source/ui/shells/grfsh.cxx
long, does SID_COLOR_TABLE
3. main/sw/source/ui/shells/frmsh.cxx
just like FN_FORMAT_FRAME_DLG
4. main/sw/sdi/_drwbase.sdi
FN_DRAW_WRAP_DLG
[
	ExecMethod = Execute;
	StateMethod = GetState ;
	DisableFlags="SW_DISABLE_ON_PROTECTED_CURSOR";
]
5. main/sw/sdi/_grfsh.sdi
6. main/sw/sdi/_frmsh.sdi
7. main/sw/sdi/swriter.sdi
8. main/sw/source/ui/frmdlg/wrap.cxx

Breakpoints on every piece of code related to FN_FORMAT_FRAME_DLG and FN_DRAW_WRAP_DLG that seemed useful, all didn't trigger before the crash.

To initialize the SID_COLOR_TABLE entry, SwFrameShell::Execute() must be called with rReq.GetSlot() == FN_FORMAT_FRAME_DLG or FN_DRAW_WRAP_DLG. That never happens. The color table doesn't get initialized. When the SfxItemSet is copied, it isn't there to be copied to the new SfxItemSet. Later code expecting it to be valid, accesses the NULL maColorTable and crashes.

It's a complete mystery why SwFrameShell::Execute() isn't getting called with rReq.GetSlot() == FN_FORMAT_FRAME_DLG or FN_DRAW_WRAP_DLG. AFAICT all the code that might call it was breakpointed, and none triggered.

Thus this is a very difficult bug to fix, as it is not caused by the presence of code taking a wrong action, but by the absence of code that should take the right action.

It could take long to examine how SwFrameShell and the tab pages relate and interact, and the multitude of events that pass between them, and figure out when and how that wFrameShell::Execute() event is meant to get sent.

Since this is an AOO 4.2.0 bug, and 4.1.x presumably works, a more productive approach might be a regression test between them, to isolate the single commit that broke it. That should immediately highlight what code changed, and where to look and what to test.

Thank you for this deep dive into the code!

As I understand it this was ongoing work that wasn't finished when the person doing it left the project.
You might find the "missing code" in other parts of AOO where it works...

Maybe this branch is of help:
https://github.com/apache/openoffice/tree/alg_writerframes

Wasn't the alg_writerframes branch already merged into trunk?

---snip---
commit 826234562a63610b5c74c9f859a817e210625bbb
Merge: 0a792eeffe 0bfedac2c8
Author: Armin Le Grand <alg@apache.org>
Date:   Wed Mar 19 16:17:02 2014 +0000

    Merge back branch alg_writerframes to trunk
    
    git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1579280 13f79535-47bb-0310-9956-ffa450edef68
---snip---



I've started a regression test but it will take a while, 9 more builds at least.

So far my regression test confirms this bug was introduced by the commit that merged the alg_writerframes branch into trunk (826234562a63610b5c74c9f859a817e210625bbb).

Now I am bisecting that branch to find which commit within it introduced the bug.

Bisection complete.

64b1462124697ddee7e7eda36bfbb70d1b558cff is the first bad commit
commit 64b1462124697ddee7e7eda36bfbb70d1b558cff
Author: Armin Le Grand <alg@apache.org>
Date:   Tue Jan 7 22:14:04 2014 +0000

    Initial version with core/draw/im-export/print/pdf/UI functionality, still stuff missing
    
    git-svn-id: https://svn.apache.org/repos/asf/openoffice/branches/alg_writerframes@1556379 13f79535-47bb-0310-9956-ffa450edef68

:040000 040000 286b1d0f170d2075e8ff3cbf7ed39b23b6c24966 512e58646ac4f738f3273c541c9db812acaeb46f M	main



It was one of the hardest bisects I ever had to do, with 5-6 patches needing backporting to get the early 2014 code to compile.

That bad commit is 13551 lines long and changes 97 files...

The unoapi test fvt.uno.sw.frame.FrameBackColor, which you run by doing:
source LinuxX86-64Env.set.sh
cd ../test
ant -Dtest.args='-tc fvt.uno.sw.frame.FrameBackColor'

is also broken by the bad commit, returning the wrong BackColor from a generated .DOC file's frame after the commit:

     [exec] SEVERE: Failure in fvt.uno.sw.frame.FrameBackColor :testFrameBackColor(fvt.uno.sw.frame.FrameBackColor): verify frame background color expected:<65280> but was:<-3151883>
     [exec] java.lang.AssertionError: verify frame background color expected:<65280> but was:<-3151883>


This should be easier to debug than the complex UI interaction involved in the "Area" tab.

Trying to take advantage of the excellent debugging work Damjan carried out with the help of Matthias, I tried to find the smallest possible solution to this problem.

I must admit I am not very sure I understood what SfxItemSets are... but the pull request I just opened _seems_ to fix the problem:
https://github.com/apache/openoffice/pull/118

I started from the observation that editing an existing frame worked, and I looked for the piece of code that does that job. It appears to be in file main/sw/source/ui/shells/frmsh.cxx starting at line 422.

The first most relevant difference with main/sw/source/ui/shells/textsh.cxx:598 is that the SfxItemSets passed contained less "ranges". Moreover the comments from the ``working'' code seem to suggest that some items must be initialized in a certain way.

I just copied and pasted those bits, and now it seems to work.

Incidentally, I had initially only added the ColorTableItem. This fixed the crash but the dialog crashed when I selected a gradient.
Then I understood I also had to provide the gradients, hatches and bitmaps.
But then any settings I selected was not transferred to the new object.
I copied all the ranges, and this seems to have fixed the problem.

(In reply to Matthias Seidel from comment #6)
> I also get a crash when editing an inserted frame by double clicking on it
> and going directly to the Wrap tab.
> It must be the first tab clicked otherwise it does not crash.

This also seems to be fixed.

(In reply to Arrigo Marchiori from comment #24)
> (In reply to Matthias Seidel from comment #6)
> > I also get a crash when editing an inserted frame by double clicking on it
> > and going directly to the Wrap tab.
> > It must be the first tab clicked otherwise it does not crash.
> 
> This also seems to be fixed.

I cannot replicate that at the moment.
I think that this was part of a problem I (myself) introduced and fixed again later...

I will build with your PR and test again.

The patch seems to fix it.

Committed to trunk with:

https://github.com/apache/openoffice/commit/f6624c039825d02292dcdd46b4cea8bf9e9b9642

Cherry-Picked for AOO42X with:

https://github.com/apache/openoffice/commit/4e6971e21453a61df6f9699a58c985d4b7f739de