https://bugs.documentfoundation.org/show_bug.cgi?id=144843

Armin Le Grand <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|[email protected] |[email protected]
                   |desktop.org                 |

--- Comment #5 from Armin Le Grand <[email protected]> ---
Took a look. It crashes in sw/source/core/docnode/ndtbl1.cxx

        const sal_uInt16 nWhich = rToFill->Which();

because rToFill which is a std::unique_ptr<SfxPoolItem>& rToFill contains a
nullptr. This is because it's called from SwFEShell::GetBoxBackground that
already gets handed in a std::unique_ptr<SvxBrushItem>& rToFill which is also
nullptr.
Origin is sw/source/uibase/shells/basesh.cxx where in SwBaseShell::ExecDlg in
case FN_FORMAT_BACKGROUND_DLG in (currently) line 2716/2717 the following is
done:

                std::unique_ptr<SvxBrushItem> aBrush;
                rSh.GetBoxBackground( aBrush );

Thus we have a code point where a nullptr is by purpose feeded to
GetBoxBackground and gets - without check - dereferenced in SwDoc::GetBoxAttr.
There are seven calls to GetBoxAttr in LO.

-> from which five DO create a default Item of some type that gets handed over.
-> from which two (one of these is used here) forward a unique_ptr.

It may be good to add a warning to SwDoc::GetBoxAttr when
std::unique_ptr<SfxPoolItem>& rToFill is not filled (is nullptr). Those two
cases are in file sw/source/core/frmedt/fetab.cxx. These are in methods

bool SwFEShell::GetBoxBackground( std::unique_ptr<SvxBrushItem>& rToFill )
const
bool SwFEShell::GetBoxDirection( std::unique_ptr<SvxFrameDirectionItem>&
rToFill ) const

GetBoxBackground forwards he Item, so we need o check where that gets called.
It has five calls from which one does not create an Item incarnation, at
sw/source/uibase/shells/basesh.cxx:2717 (our crash here).

GetBoxDirection also forwards the Item, there are two calls, both create Items,
so no problem.

I do not see a relationship to the changes mentioned as
(1e2682235cded9a7cd90e55f0bfc60a1285e9a46) and which I did. That change did not
remove any SfxPoolItem derived creations of items.

Thus the problem is a sw/source/uibase/shells/basesh.cxx:2717 - I will change
and check.

Note: It is unfortunately no obvious that GetBoxBackground && GetBoxDirection
*require* an incarnation of the intended SfxItem to be handed over - a bad trap
for every user. People used o LO learned (the hard way) to check the called
method...

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to