AW->TL: editengine/outliner, wrong owner in CVS?

*** Issue 68371 has been marked as a duplicate of this issue. ***

Yet another case where the EditView (OutlinerView) are destroyed and a call from
sd is made to OutlinerView::SetWindow (which when looking in the implementation
could hardly be at fault).

TL->CL: Please have a look. Thanks!

cl->af: this looks like a problem with an outdated view pointer after switching
the view during a document wide search&replace operation

*** Issue 68354 has been marked as a duplicate of this issue. ***

wrong component

set target to 3.x

Also occurred in newer Valgrind run on BEA300.m2, VID: 150. 

Detailed Valgrind info:

Invalid read of size 4
    EditView::SetWindow(Window*) editview.cxx:316 0xC8FD2F3
    OutlinerView::SetWindow(Window*) outlvw.cxx:1297 0xC95B252
    sd::Outliner::SetViewShell(sd::ViewShell*) Outliner.cxx:1537 0xBF90545
    sd::Outliner::StartSearchAndReplace(SvxSearchItem const*) Outliner.cxx:526
0xBF8DE17
    sd::FuSearch::SearchAndReplace(SvxSearchItem const*) fusearch.cxx:161 0xC1F04CF
    sd::DrawDocShell::Execute(SfxRequest&) docshel3.cxx:183 0xBFDE9A0
    SfxStubDrawDocShellExecute(SfxShell*, SfxRequest&) sdslots.hxx:14683 0xBFDA40B
    SfxShell::CallExec(void (*)(SfxShell*, SfxRequest&), SfxRequest&)
shell.hxx:204 0x4ACA9B1
    SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, unsigned
char) dispatch.cxx:306 0x4AC4A27
    SfxDispatcher::_Execute(SfxShell&, SfxSlot const&, SfxRequest&, unsigned
short) dispatch.cxx:1073 0x4AC5FF7
    SfxBindings::Execute_Impl(SfxRequest&, SfxSlot const*, SfxShell*)
bindings.cxx:1694 0x4ABF03F
    SfxBindings::Execute_Impl(unsigned short, SfxPoolItem const**, unsigned
short, unsigned short, SfxPoolItem const**, unsigned char) bindings.cxx:1590
0x4ABEB0B
  
ADDR:  Address 0x693193c is 4 bytes inside a block of size 8 free'd
    free vg_replace_malloc.c:323 0x401D599
    rtl_freeMemory alloc_global.c:301 0x40218D6
    NO_SYMBOL() soffice.bin 0x8049025
    operator delete(void*) soffice.bin 0x8049074
    EditView::~EditView() editview.cxx:175 0xC8FCC83
    OutlinerView::~OutlinerView() outlvw.cxx:80 0xC957E05
    sd::OutlineView::~OutlineView() outlview.cxx:218 0xBF73CA3
    sd::OutlineViewShell::~OutlineViewShell() outlnvsh.cxx:286 0xBF6A948
    void boost::checked_delete<sd::OutlineViewShell>(sd::OutlineViewShell*)
checked_delete.hpp:30 0xC28A060
   
boost::checked_deleter<sd::OutlineViewShell>::operator()(sd::OutlineViewShell*)
const checked_delete.hpp:46 0xC28A044
    boost::detail::sp_counted_base_impl<sd::OutlineViewShell*,
boost::checked_deleter<sd::OutlineViewShell> >::dispose() shared_count.hpp:262
0xC28A7C0
    boost::detail::sp_counted_base::release() shared_count.hpp:143 0xBF0D67F

TESTS: g_findreplace

Changed prio to P2, because this is a potential GPF.

Changed target.

.

We have here a valid Outliner object that uses an already destroyed OutlinerView
object.

My hypothesis of how this could happen:

A search is started in an outline view.  This leads to a call of
Outliner::Implementation::ProvideOutlinerView() where the OutlinerView of the
current OutlineViewShell is stored in mpOutlineView.  The search switches from
view shell to view shell until it finally fails and switches back to outline
view.  However, the OutlineViewShells and their OutlinerViews on which the
search starts and where it ends are not identical.  Switching to another view
shell destroyes the current one.  As a result mpOutlineView points to an already
destroyed OutlinerView object.

When the search is triggered a second time then ProvideOutlinerView() is called
again.  It just checks the *type* of the current view shell.  As this is the
same as the one the last time ProvideOutlinerView() was called it does not
modify the value of mpOutlineView.  The following access of mpOutlineView
triggers the valgrind error and possibly a GPF.


If this hypothesis is correct then this error can be fixed by resetting
mpOutlineView when the OutlinerView it points to is destroyed.  To ways to do
this come to mind:

- Listen to changes of the main view shell.  When a currently avtive
OutlineViewShell is deactivated then reset mpOutlineView.

- Store a shared pointer to the view shell from which mpOutlineView is
initialized.  When the view shell is destroyed the shared pointer is set to NULL
(even when later another OutlineViewShell is created at the same place in memory
as the previous one).  In ProvideOutlinerView check the shared pointer and reset
mpOutlineView when the shared pointer is empty.

With the BEA300 m2 I am not able to run the test together with Valgrind.
With the OOO300 m3 I am, but can not reproduce this specific iusse (though I can
reproduce other Valgrind issues.)

Because of this and because I do not know of any real crashes caused by this
Valgrind problem I set the the target to OOo 3.1.

Setting target to OOo 3.2 and priority to P3 because of time constraints, this
is not a crash, and still don't know the root cause.

Setting target to OOo 3.3.

Changing target.

Reset assigne to the default "issues@openoffice.apache.org".