Issue 123914

Confirmed with
AOO410m1(Build:9750)  -  Rev. 1551264
2013-12-17_04:10:52 - Rev. 1551455
Debian

How do I get MailMerge Wizard in Tools?

(In reply to Armin Le Grand from comment #2)
> How do I get MailMerge Wizard in Tools?

Oops, sorry, Step before "2." missingmissing:
1.2. Open downloaded document

Okay, thanks.

I get the following assertions:

******************************************************************************
dbgsv.log
Thu Jan 30 15:28:22 2014

Error: Property array is not sorted From File C:/aoo/svn_trunk45/main/cppuhelper/source/propshlp.cxx at Line 1106
Error: hyperlink without an URL --> no export to ODF From File c:/aoo/svn_trunk45/main/xmloff/source/text/txtparae.cxx at Line 3169

And a crash in SwMailMergeWizard::CreateTargetDocument(). The first statement - GetSwView() - accesses the member m_pSwView which is 0xcccccccc in my stack, so it crashes. It gets only set in the SwMailMergeWizard constructor, so must be already wrong there. Lets see...

Starting new, the MailMerge Wizard gets constructed with a valid view from SwMailMergeWizardExecutor::ExecuteMailMergeWizard. It is taken from ::GetActiveView() which uses GetActiveView() which uses SfxViewShell::Current() and casts to SwView which is correct (debugger shows that it indeed is a SwView). What may go wrong?

The call in SwMailMergeWizard::CreateTargetDocument() using the view (still intact) gets to SwNewDBMgr::MergeDocuments, all okay. It crashes in SwNewDBMgr::MergeDocuments in

uno::Reference< lang::XUnoTunnel > xWorkDocShell( xClone->createClone(), uno::UNO_QUERY);

Lets see...

Crash is at leaving SwDoc::CreateCopy, so probably at the destruction of some local data. As candidates we mostly have a local SfxItemSet, so I need sfx2 with debug...

The pRet->SetTmpDocShell( (SfxObjectShell*)NULL ); call in SwDoc::CreateCopy deletes pRet again, this is surely not intended. This happens due to the following stack:

>	sw.dll!SwDoc::~SwDoc()  Line 473	C++
 	sw.dll!SwDoc::`vector deleting destructor'()  + 0x50 bytes	C++
 	sw.dll!SwDocShell::RemoveLink()  Line 526 + 0x24 bytes	C++
 	sw.dll!SwDocShell::~SwDocShell()  Line 433	C++
 	sw.dll!SwDocShell::`vbase destructor'()  + 0xf bytes	C++
 	sw.dll!SwDocShell::`vector deleting destructor'()  + 0x50 bytes	C++
 	tl.dll!5b1cdba0() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for tl.dll]	
 	tl.dll!5b1826b5() 	
 	sot.dll!6ccb6d97() 	
 	sw.dll!SfxObjectShellLock::operator=(const SfxObjectShellLock & rObj)  Line 803 + 0x5d bytes	C++
 	sw.dll!SwDoc::SetTmpDocShell(SfxObjectShellLock rLock)  Line 1849 + 0x3f bytes	C++
 	sw.dll!SwDoc::CreateCopy(bool bCallInitNew)  Line 1207	C++
 	sw.dll!SwXTextDocument::createClone()  Line 3254 + 0x17 bytes	C++

It is surely not intended that the just created clone is deleted again before it even gets returned. Jumping over the SetTmpDocShell line does solve the direct crash, but the destructor for the clone is called nut much later and crashes.
I do not know enough about Writer and DocShells/Docs to know what is intended to happen here, but it seems as if we have a lifetime problem. Setting Olli to CC...

Compared with a simple HelloWorld doc which works, inside SwDoc::CreateCopy the HelloWorld does not set xTmpDocShell in the created copy of SwDoc while in the bugdoc it gets set from the following stack:

>	sw.dll!SwDoc::SetTmpDocShell(SfxObjectShellLock rLock)  Line 1849	C++
 	sw.dll!SwOLENode::MakeCopy(SwDoc * pDoc, const SwNodeIndex & rIdx)  Line 467	C++
 	sw.dll!SwNodes::_CopyNodes(const SwNodeRange & rRange, const SwNodeIndex & rIndex, unsigned char bNewFrms, unsigned char bTblInsDummyNode)  Line 2161 + 0x45 bytes	C++
 	sw.dll!SwDoc::CopyWithFlyInFly(const SwNodeRange & rRg, const unsigned short nEndContentIndex, const SwNodeIndex & rInsPos, const SwPaM * pCopiedPaM, const unsigned char bMakeNewFrms, const unsigned char bDelRedlines, const unsigned char bCopyFlyAtFly)  Line 1343	C++
 	sw.dll!SwDoc::CopyLayoutFmt(const SwFrmFmt & rSource, const SwFmtAnchor & rNewAnchor, bool bSetTxtFlyAtt, bool bMakeFrms)  Line 503	C++
 	sw.dll!SwDoc::CopyFlyInFlyImpl(const SwNodeRange & rRg, const unsigned short nEndContentIndex, const SwNodeIndex & rStartIdx, const bool bCopyFlyAtFly)  Line 1606 + 0x22 bytes	C++
 	sw.dll!SwDoc::CopyWithFlyInFly(const SwNodeRange & rRg, const unsigned short nEndContentIndex, const SwNodeIndex & rInsPos, const SwPaM * pCopiedPaM, const unsigned char bMakeNewFrms, const unsigned char bDelRedlines, const unsigned char bCopyFlyAtFly)  Line 1371	C++
 	sw.dll!SwDoc::CopyImpl(SwPaM & rPam, SwPosition & rPos, const bool bMakeNewFrms, const bool bCopyAll, SwPaM * const pCpyRange)  Line 1262	C++
 	sw.dll!SwDoc::CopyRange(SwPaM & rPam, SwPosition & rPos, const bool bCopyAll)  Line 732 + 0x21 bytes	C++
 	sw.dll!SwDoc::Paste(const SwDoc & rSource)  Line 1242	C++
 	sw.dll!SwDoc::CreateCopy(bool bCallInitNew)  Line 1205	C++
 	sw.dll!SwXTextDocument::createClone()  Line 3254 + 0x17 bytes	C++
 	sw.dll!SwNewDBMgr::MergeDocuments(SwMailMergeConfigItem & rMMConfig, SwView & rSourceView)  Line 2935 + 0x32 bytes	C++
 	swui.dll!SwMailMergeWizard::CreateTargetDocument()  Line 304	C++
 	swui.dll!SwMailMergePrepareMergePage::commitPage(svt::WizardTypes::CommitPageReason _eReason)  Line 196	C++

As can be seen when the doc contains an OLE container, SwOLENode::MakeCopy is called which contains code to create and set a SfxObjectShell if none exists at the local SwDoc. This - AFAIUnderstandThis - gives the ownership of the SwDoc to the created SfxObjectShell via RefCounting. When then setting this to zero in the mail merge of course the doc is deleted.
This means that all Writer docs containing OLEs will break the MailMerge wizard. I will check what happens if I avoid that code in SwOLENode::MakeCopy...

Avoiding creation makes the doc and wizard survive. There are three places in SW where GetTmpDocShell is checked and obviously the cration of a temp SwDocShell is handled, all with the same (german) comment

// es wurde in der CORE eine neu angelegt (OLE-Objekte kopiert!)

which is like

// there was one newly created (OLE copied!)

Looks as if someone implemented this by purpose to handle a missing SwDocShell in SwOLENode::MakeCopy to have a way to get a EmbeddedObjectContainer and to have a SvPersist where to place a copy of the OLE data. All three copies call SwTransferable::InitOle and then also call SetTmpDocShell(NULL) as the wizard does. But thez also use a SfxObjectShellLock aDocShellRef to hold the return value of GetTmpDocShell. Lets see how far this can be done in the wizard, too (the SwTransferable::InitOle call may be missing anyways)...

It also works when forcing bCallInitNew to true in SwDoc::CreateCopy; then the SfxObjectShell pRetShell prepared there seems so far prepared that SwOLENode::MakeCopy does not need to create and set an own SwDocShell using SetTmpDocShell and all is good; but this would require to know that OLEs are included and this is needed before the Paste call.
It would also work to use any instance of a class that holds a reference to SwDoc during the call to SetTmpDocShell(NULL), or simply use the (surprisingly public) methods SwDoc::acquire and SwDoc::release (again surprisingly not initiating the self-destruction of the SwDoc on getting to zero). All this only needed when testing GetTmpDocShell is non-zero. Checking this...

This does the trick, preparing commit. Olli, please have a look at it!

"alg" committed SVN revision 1563194 into trunk:
i123914 Use an own hold on the newly created SwDoc when a call to SetTmpDocSh...

Okay, done.

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

@Armin:
Thx a lot!

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

(In reply to Rainer Bielefeld from comment #0)
> Steps how to reproduce Reproducible with "AOO 4.0.1   – German UI / German
> locale  [Rev. 1524958 2013-09-20 11:40:29]" on  German WIN7 Home Premium
> (64bit)", “historic”  4.0  User Profile used for all  predecessor versions
> 
> 1. Download "New Minimum Sample Document"  from 
>    <https://bugs.freedesktop.org/attachment.cgi?id=46731>
> 2. Menu ' Tools -> Mail Merge Wizard -> Use Current -> [Next]
> 3. Step 2: E-Mail (does not matter) -> [Next]
> 4. Step 3: Select "Bibilo" as address list  (does not matter) -> [Next]
> 5. Step 4: No salutation,   -> [Next]   (will skip Step 4)
> 6. Step 6: -> [Next]
>    Bug: CRASH during creation of first document                       :-(
> 
> 
> Additional Info:
> ----------------
> (a) Still Reproducible with server installation of "AOO 4.1.0-Dev – English 
> UI /
>     English locale - [AOO410m1(Build:9750)  -  Rev. 1546757 - 2013-12-02]" on
>     German WIN7 Home Premium (64bit)", own separate user profile.
> (b) Still worked fine with sever installation of "OOo 3.3.0 English UI / 
>     German locale [OOO330m20 (Build 9567)]" on  WIN7  Home Premium  (64bit)
> DE 
> (c) Still worked fine with OOo 3.3.3, so REGRESSION
> (d) For more details see LibO "Bug#35404 - Particular documents crash 
>     during e-mail mail merge". Due to that Bug report: OS=ALL, CONFIRMED

can not the entry to execute this step(there is no item of "Bibilo")
--4. Step 3: Select "Bibilo" as address list  (does not matter) -> [Next]

can not find the entry to execute this step(there is no item of "Bibilo")
--4. Step 3: Select "Bibilo" as address list  (does not matter) -> [Next]