OK in m103, broken in m106

so candidates for regression are: sw34bf04 and sw34bf05

Further investigation revealed that the crash is caused by a change in sw34bf04

this one somehow manages not to crash on solaris, which has confused me.

crash happens because in wrtw8sty.cxx there are WW8_WrPlcSepx members
aSect and pAttrs and they are out of sync.
aSect is appended to 5 times, then WriteKFTxt is called which
initializes pAttrs to the size of aSect,
then aSect gets another element,
then crash on access to pAttrs[5] while it is only 5 in size.

The "naughty change" is 35b0567d3368.

diff --git a/sw/source/filter/ww8/ww8atr.cxx b/sw/source/filter/ww8/ww8atr.cxx
--- a/sw/source/filter/ww8/ww8atr.cxx
+++ b/sw/source/filter/ww8/ww8atr.cxx
@@ -439,10 +439,20 @@
     //section.
     bool bBreakSet = false;
 
+    const SwPageDesc * pPageDesc = rNd.FindPageDesc(sal_False);
+	
+    if (pAktPageDesc != pPageDesc)
+    {
+        bBreakSet = true;
+        bNewPageDesc = true;
+        pAktPageDesc = pPageDesc;
+    }
+
     if ( pSet && pSet->Count() )
     {
-        if ( SFX_ITEM_SET == pSet->GetItemState( RES_PAGEDESC, false, &pItem )
-             && ( (SwFmtPageDesc*)pItem )->GetRegisteredIn() )
+        bool bGotItem = 
+        if ( SFX_ITEM_SET == pSet->GetItemState( RES_PAGEDESC, false, &pItem ) && 
+             dynamic_cast<const SwFmtPageDesc*>(pItem)->GetRegisteredIn() != NULL)
         {
             bBreakSet = true;
             bNewPageDesc = true;

The superfluous line with "bGotItem" was corrected in the next changeset.

This was a fix for
http://openoffice.org/bugzilla/show_bug.cgi?id=106749

Indeed this change causes the "out of sync problem": MsWordExportBase::OutputSectionBreaks() finds a new PageDesc and so calls "PrepareNewPageDesc" (that finally appends another section).

Unfortunately the change in ww8atr.cxx is not documented, so we can only guess.
Either the code in wrtw8sty.cxx is wrong or it is wrong that a new section is inserted so late in the game. Or both. :-)

there is apparently a limitation to the WW8 export:
the page descriptors in endnotes cannot be exported.

in WW8_WrPlcSepx::WriteKFTxt the headers/footers are exported.
in the WW8 format, the endnotes come after the headers/footers.
so if a page descriptor contains header/footer it must be
known before WriteKFTxt is called, which apparently isn't the case here.

given the crash in this issue, the WW8 export really does not expect this.

i don't really know if the fix for the other issue that
introduced this regression is the right one.

the second array (pAttrs) is necessary because the section properties
are actually stored separate from the text, and far later.

i've tried putting in some hacks to prevent the 2 arrays from
going out of sync by preventing the insertion of new sections
after the headers/footers have been written.

Created attachment 76480 [details]
disable section breaks in endnotes

hack to disable the generation of section breaks in endnotes,
which apparently don't work anyway.

one problem i've noticed is that it's necessary to disable the change in
OutputSectionBreaks in endnotes.
just disabling the functions that add to aSects results in not crashing
on export, but the endnote in the bugdoc then gets an additional
section break character.

i wonder if this can be a problem elsewhere (not in endnotes),
or if it is intentional.

anyway, right now i'm not sure if this patch is the way to go,
or if the change for issue 106749 should be reverted.

I think it's OK to have this additional section break, so please go ahead with your patch

Created attachment 76483 [details]
document with page break in endnotes

by cunning use of a text editor i've created a document that,
when stored as WW8, crashes DEV300_m103 (which is not affected
by the regression).

this demonstrates that page breaks in endnotes are not really
a new problem, and something like the patch is necessary.

fixed in CWS sw34bf06:
http://hg.services.openoffice.org/hg/cws/sw34bf06/rev/c1d78b76cbb1

getting rid of value "enhancement" for field "severity".
For enhancement the field "issue type" shall be used.

Verified it on Aoo_Trunk_20120616.1800.1350879 and it does not reproduce, so close it as fixed.