Change-Id: If9c7a3239fceba9a2db3a5905ccaa7fa9adadb08
Reviewed-on: https://gerrit.libreoffice.org/39099Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ie0e2ecaadb49273cb4e78bc894111523940e7c8e
Reviewed-on: https://gerrit.libreoffice.org/39098Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

and drop unused ERRCODE_AREA_OFA_END constant

Change-Id: Ic34ecda7f842c5db93807b3f21aa1062966ca523
Reviewed-on: https://gerrit.libreoffice.org/39089Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>

I'm not exactly sure what role the Endnote Symbol char style
plays, but it is only related to Endnote Characters, not the
main footnote text.

Note: the existing mapping rarely takes effect since MSWord
exports the stylename in lower-case. Unfortunately, there is
no history to indicate why "Endnote Text" is mapped to
"Endnote Symbol". That looks like an error to me.

related to tdf#82173 which exposed this issue.

Change-Id: Ie92f527b1e594fd571f1118d18a8ff225cfc2314
Reviewed-on: https://gerrit.libreoffice.org/38605Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>

This makes the pivot table exported to XLSX refreshable (does not
crash Excel on pivot table refresh).

Change-Id: Icc35795cd116e091b75bb1d4a603c52ccc71c44d
Reviewed-on: https://gerrit.libreoffice.org/39018Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>

Change-Id: I3f30b5ab985c2ff709116568905b941c5d50fd1a

Change-Id: I307662ef0d8360da3cbc7edc96890575715bbf07

Change-Id: I3dce45da77c6ab21be5a999d4ea5b7944a07bbd7

Change-Id: I8f02cfdcaa1a5d2ce981b5de1b9754da36760649
Reviewed-on: https://gerrit.libreoffice.org/39124Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

I didn't find UI in Word to create

<w:spacing w:line="-260" w:lineRule="auto"/>

the equivalent markup when you set line spacing to exactly 13pt for new
documents is:

<w:spacing w:line="260" w:lineRule="exact"/>

The OOXML spec and Microsoft's implementer notes ([MS-OI29500]) is also
pretty silent about what a negative value means. However, if this markup
is converted to WW8 by Word, then the WW8 LPSD structure is like this
(as presented by doc-dumper):

<lspd type="LSPD" offset="5086">
  <dyaLine value="0xfefc"/>
  <fMultLinespace value="0x1"/>
</lspd>

For the 0xfefc value the [MS-DOC] spec clearly states that means the
type of the spacing is "exactly", with the value of 0x10000-0xfefc, i.e.
the same 260 twips.

Change-Id: I84b485d02dea49c610b6df2e06ccce03e1d29d21
Reviewed-on: https://gerrit.libreoffice.org/39091Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

This file is generated by "make vim-ide-integration"

Change-Id: I9355bc36b2a654efd6183b268662b10b224f2117
Reviewed-on: https://gerrit.libreoffice.org/39108Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: Idb22bd00572d362eb2cc0137fe01835d6c28fcf8

xmlparse.c has a
 #define buffer something

later
 #include something

that happens to use buffer as a parameter.

Change-Id: I7378aa9481b30364097c70317c794c0bcca2f05c
Reviewed-on: https://gerrit.libreoffice.org/39109Reviewed-by: jan iversen <jani@libreoffice.org>
Tested-by: jan iversen <jani@libreoffice.org>

Change-Id: I5ee2a60f80728a2cca1401e43c8e27f852bfc657
Reviewed-on: https://gerrit.libreoffice.org/39116Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Iaa23361510b1aa1eebfa6618b526fc7d9d6fa537

Change-Id: I5c9b27862da6ac76ae38542f85a51f9aefdd013d
Reviewed-on: https://gerrit.libreoffice.org/39111Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Allows you to remove an entry along with its children
without selecting the entry.

Change-Id: Ie833df5e0d2d3bc86ed01a70dc6f042ebb6d6a47
Reviewed-on: https://gerrit.libreoffice.org/38971Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>

Change-Id: I7cbea9381bc993e7894603c731ab0ac54e80d4b4
Reviewed-on: https://gerrit.libreoffice.org/39049Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

The only remaining difference is that in the system-xmlsec case we work
with the default key manager, not with the one that's only added by our
xmlsec patches.

This works for me for the uses I know of (see
<https://lists.freedesktop.org/archives/libreoffice/2017-February/076947.html>
for the motivation): signing and verifying of different signatures (bad
signature, good with non-trusted CA, good with trusted CA) with
software-based certificates all behave as expected.

Change-Id: If3f3e2b8373ab7397db3f98070a5a2ce51fa7c06
Reviewed-on: https://gerrit.libreoffice.org/39075Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

The ClearSwLayouterEntries() accesses anchored objects and if they are
anchored in footnotes then RemoveFootnotes() has already deleted them.

(regression from 962d0500)

Invalid write of size 1
   at 0x4143CCB3: SwAnchoredObject::SetTmpConsiderWrapInfluence(bool) (anchoredobject.cxx:739)
   by 0x414D8A21: SwObjsMarkedAsTmpConsiderWrapInfluence::Clear() (objstmpconsiderwrapinfl.cxx:58)
   by 0x414C943E: SwLayouter::ClearObjsTmpConsiderWrapInfluence(SwDoc const&) (layouter.cxx:401)
   by 0x411DBE57: sw::DocumentLayoutManager::ClearSwLayouterEntries() (DocumentLayoutManager.cxx:504)
   by 0x414D05D9: SwRootFrame::DestroyImpl() (newfrm.cxx:594)
   by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389)
   by 0x419E8171: std::_Sp_counted_deleter<SwRootFrame*, void (*)(SwFrame*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:464)
   by 0x40EB6DB5: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:150)
   by 0x40EB5E76: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:662)
   by 0x419E65F9: std::__shared_ptr<SwRootFrame, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:928)
   by 0x419E6615: std::shared_ptr<SwRootFrame>::~shared_ptr() (shared_ptr.h:93)
   by 0x419E619D: SwViewShell::~SwViewShell() (vnew.cxx:285)
  Address 0x5feb6eee is 334 bytes inside a block of size 488 free'd
   at 0x4C2F21A: operator delete(void*) (vg_replace_malloc.c:576)
   by 0x41488962: SwFlyAtContentFrame::~SwFlyAtContentFrame() (flyfrms.hxx:134)
   by 0x41535AFC: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391)
   by 0x415360BD: SwLayoutFrame::DestroyImpl() (ssfrm.cxx:477)
   by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389)
   by 0x414A2FF4: sw_RemoveFootnotes(SwFootnoteBossFrame*, bool, bool) (ftnfrm.cxx:852)
   by 0x414A3104: sw_RemoveFootnotes(SwFootnoteBossFrame*, bool, bool) (ftnfrm.cxx:874)
   by 0x414A321A: SwRootFrame::RemoveFootnotes(SwPageFrame*, bool, bool) (ftnfrm.cxx:897)
   by 0x414D0558: SwRootFrame::DestroyImpl() (newfrm.cxx:585)
   by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389)
   by 0x419E8171: std::_Sp_counted_deleter<SwRootFrame*, void (*)(SwFrame*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:464)
   by 0x40EB6DB5: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:150)
   by 0x40EB5E76: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:662)
   by 0x419E65F9: std::__shared_ptr<SwRootFrame, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:928)
   by 0x419E6615: std::shared_ptr<SwRootFrame>::~shared_ptr() (shared_ptr.h:93)
   by 0x419E619D: SwViewShell::~SwViewShell() (vnew.cxx:285)

Change-Id: I147f46d49c90de46189ad34feed66c289adddc15

Use temporary SAL_DEBUGs in your local tree instead if/when you need
to trace these constructors and destructors.

Change-Id: Icc52c905205914f0e5b911a2dae8322e99e9234e

Change-Id: Ibbd83a7d69a27ab96b99d28e1d4a1f65af63b82f
Reviewed-on: https://gerrit.libreoffice.org/39037Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: If4de6e4cdebb082cbe8faa9392fceb61c3f8fb9e

Change-Id: I38cb79abb2a495ccca454903bc46b407009e8290
Reviewed-on: https://gerrit.libreoffice.org/39084Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

for some reason they are not set and cause parse warnings

Change-Id: I1bbc14da8cd7f4cbde8e59934b6ace932245e2a1
Reviewed-on: https://gerrit.libreoffice.org/39093Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

tde and mozilla externals are gone.
breakpad, bzip2 and mDNSResponder are omitted.

filter out 'orcus-parser\' line, 'orcus-parser' is still in
iwyu_EXTERNALS

Change-Id: Ida7155b8b00b651146c4307286e9eafbdadb5917
Reviewed-on: https://gerrit.libreoffice.org/39092Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

no logic change intended.

follow some shellcheck advises:
use block for redirects to same file for better style (SC2129)
double quote vars (SC2086)
ignore false positive warnings SC1003 and SC2016

Change-Id: Ic3a01484d4d13c8d23662ee24c46b166ee006cd4
Reviewed-on: https://gerrit.libreoffice.org/39090Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Last holdout for separate xmlSec init removed, cf.
ed92db7a

Change-Id: I46a05074706bba77ebc488f0df296e35e2b7d553

removed with 06d7dbb3

Change-Id: I7e01cc1f3551cd18c8fe09e908b6dbab75e2ae2d

Take it into use in a couple of places.

Change-Id: I72127f4236220fbe6fbf9ea25cdd56470be89961
Reviewed-on: https://gerrit.libreoffice.org/38997Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I277f30129560ea9fa76d6439a60bb191358df99d
Reviewed-on: https://gerrit.libreoffice.org/39088Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

This reverts commit d36dc7b3.  Turns out e.g.
tb75-lilith has a 'file' command that doesn't print "execfn:" information, just

> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UITest/calc_demo/done.core/core.24697: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/instdir/program/soffice'

(<https://ci.libreoffice.org/job/lo_tb_master_linux_dbg/13930/console>), but
with a truncated "from:" path, so would probably be little benefit to try to get
the path from the "from:" instead of (or in addition to) the "execfn:"
information (where the latter appears to be more accurate at least with my local
file-5.29-4.fc25.x86_64).

also when we could not create lockfile, not only when open as readonly

Change-Id: Ied53bbfe47669f62553d97d81f0bed156ae58887
Reviewed-on: https://gerrit.libreoffice.org/39054Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>

Change-Id: Idb4ee77ed83c17f8040cf1a5852ae1ac8fa855d6

...that dumped a core file.  Is it just that the pathname is too long and gets
truncated?  To be reverted again.

Change-Id: I2e571cf7d5d3a128e8875e01df37bfccadefe80a

Change-Id: Ib0c083803024d223f62b91ec54850b84eb68a758
Reviewed-on: https://gerrit.libreoffice.org/39033Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>

Change-Id: I62caffcacb710aa079ddc9c81fb49f702cdc84af

In SwContentFrame::MakeAll() the pPre (previous frame) is deleted in a
call to MoveFwd().  This SwTextFrame is inside of a footnote, and
the SwFlowFrame::CutTree() for whatever reason wants to format all
of the SwTextFrames inside the same SwFootnoteFrame, which causes
the pPre to be joined with another one.

Let's try to avoid that by checking that it's still in the layout after
the call to MoveFwd(); on the one hand it's not obvious that this frame
is important enough that it should be kept alive with ForbidDelete(),
on the other hand i have no idea if simply removing the ValidateSz()
call would introduce new loops or whatever.

Invalid read of size 4
 at 0x414E8D14: SwFrame::IsSctFrame() const (frame.hxx:1018)
 by 0x41A85A29: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1713)
 by 0x41A7F499: SwFrame::OptPrepareMake() (calcmove.cxx:368)
 by 0x41ADF0CF: SwFrame::OptCalc() const (frame.hxx:892)
 by 0x41ADCC07: SwLayAction::FormatContent_(SwContentFrame const*, SwPageFrame const*) (layact.cxx:1789)
 by 0x41ADC195: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1620)
 by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760)
 by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351)
 by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133)
 by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711)
Address 0x530ccf80 is 160 bytes inside a block of size 264 free'd
 at 0x4C2ED4A: free (vg_replace_malloc.c:530)
 by 0x4E5BCD0: rtl_freeMemory_SYSTEM(void*) (alloc_global.cxx:271)
 by 0x4E5C00A: rtl_freeMemory (alloc_global.cxx:341)
 by 0x4E5AAA0: rtl_cache_free (alloc_cache.cxx:1231)
 by 0xEFC9A6F: FixedMemPool::Free(void*) (mempool.cxx:49)
 by 0x41CA7DFA: SwTextFrame::operator delete(void*, unsigned long) (txtfrm.hxx:377)
 by 0x41C9F7B6: SwTextFrame::~SwTextFrame() (txtfrm.cxx:415)
 by 0x41B5B74C: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391)
 by 0x41C1589A: SwTextFrame::JoinFrame() (frmform.cxx:656)
 by 0x41C153B1: SwTextFrame::AdjustFollow_(SwTextFormatter&, int, int, unsigned char) (frmform.cxx:555)
 by 0x41C172E1: SwTextFrame::FormatAdjust(SwTextFormatter&, WidowsAndOrphans&, int, bool) (frmform.cxx:1108)
 by 0x41C18D5E: SwTextFrame::Format_(SwTextFormatter&, SwTextFormatInfo&, bool) (frmform.cxx:1550)
 by 0x41C19340: SwTextFrame::Format_(OutputDevice*, SwParaPortion*) (frmform.cxx:1660)
 by 0x41C19CD8: SwTextFrame::Format(OutputDevice*, SwBorderAttrs const*) (frmform.cxx:1807)
 by 0x41A847A1: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1393)
 by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346)
 by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761)
 by 0x41A973E7: SwFlowFrame::CutTree(SwFrame*) (flowfrm.cxx:424)
 by 0x41A979AE: SwFlowFrame::MoveSubTree(SwLayoutFrame*, SwFrame*) (flowfrm.cxx:592)
 by 0x41ACFB69: SwContentFrame::MoveFootnoteCntFwd(bool, SwFootnoteBossFrame*) (ftnfrm.cxx:2756)
 by 0x41A9B78E: SwFlowFrame::MoveFwd(bool, bool, bool) (flowfrm.cxx:1813)
 by 0x41A85864: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1681)
 by 0x41A7F499: SwFrame::OptPrepareMake() (calcmove.cxx:368)
 by 0x41ADF0CF: SwFrame::OptCalc() const (frame.hxx:892)
 by 0x41ADCC07: SwLayAction::FormatContent_(SwContentFrame const*, SwPageFrame const*) (layact.cxx:1789)
 by 0x41ADC195: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1620)
 by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760)
 by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351)
 by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133)
 by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711)

Change-Id: I35b27a32608d4dcf98e0933cce76ce5ddb1c09d9

After inserting a header in the bugdoc, during SwFrame::Calc of a
SwTextFrame that is in a footnote, it decides move forward to the next
page.  This deletes the SwFootnoteFrame and SwFootnoteContFrame that
lcl_FormatContentOfLayoutFrame() are iterating over.

For want of a more elegant solution, use a big hammer to prevent the
problem and try to clean up so that no empty SwFootnoteFrame and
SwFootnoteContFrame remain (as that is known to crash in other places,
see commit c9fb3476)

Invalid read of size 8
   at 0x414E1F96: SwFrame::GetNext() (frame.hxx:485)
   by 0x41AFDD07: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:646)
   by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
   by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
   by 0x41AFDEA7: SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (objectformattertxtfrm.cxx:696)
   by 0x41AAA680: SwFlyAtContentFrame::MakeAll(OutputDevice*) (flycnt.cxx:415)
   by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346)
   by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761)
   by 0x41AA8927: SwFlyFrame::Calc(OutputDevice*) const (fly.cxx:2559)
   by 0x41ADB36B: SwLayAction::FormatLayoutFly(SwFlyFrame*) (layact.cxx:1414)
   by 0x41AF9658: SwObjectFormatter::FormatObj_(SwAnchoredObject&) (objectformatter.cxx:321)
   by 0x41AFCB6E: SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool) (objectformattertxtfrm.cxx:126)
   by 0x41AF9A6A: SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (objectformatter.cxx:443)
   by 0x41AFD275: SwObjectFormatterTextFrame::DoFormatObjs() (objectformattertxtfrm.cxx:328)
   by 0x41AF924A: SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (objectformatter.cxx:191)
   by 0x41ADC213: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1633)
   by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760)
   by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351)
   by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133)
   by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711)
 Address 0x505541a8 is 72 bytes inside a block of size 272 free'd
   at 0x4C2F21A: operator delete(void*) (vg_replace_malloc.c:576)
   by 0x41AD371A: SwFootnoteFrame::~SwFootnoteFrame() (ftnfrm.hxx:52)
   by 0x41B5B74C: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391)
   by 0x41A97294: SwFlowFrame::CutTree(SwFrame*) (flowfrm.cxx:406)
   by 0x41A979AE: SwFlowFrame::MoveSubTree(SwLayoutFrame*, SwFrame*) (flowfrm.cxx:592)
   by 0x41ACFB69: SwContentFrame::MoveFootnoteCntFwd(bool, SwFootnoteBossFrame*) (ftnfrm.cxx:2756)
   by 0x41A9B78E: SwFlowFrame::MoveFwd(bool, bool, bool) (flowfrm.cxx:1813)
   by 0x41A85864: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1681)
   by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346)
   by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761)
   by 0x41AFDCFB: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:644)
   by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
   by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
   by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
   by 0x41AFDEA7: SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (objectformattertxtfrm.cxx:696)
   by 0x41AAA680: SwFlyAtContentFrame::MakeAll(OutputDevice*) (flycnt.cxx:415)
   by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346)
   by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761)
   by 0x41AA8927: SwFlyFrame::Calc(OutputDevice*) const (fly.cxx:2559)
   by 0x41ADB36B: SwLayAction::FormatLayoutFly(SwFlyFrame*) (layact.cxx:1414)
   by 0x41AF9658: SwObjectFormatter::FormatObj_(SwAnchoredObject&) (objectformatter.cxx:321)
   by 0x41AFCB6E: SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool) (objectformattertxtfrm.cxx:126)
   by 0x41AF9A6A: SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (objectformatter.cxx:443)
   by 0x41AFD275: SwObjectFormatterTextFrame::DoFormatObjs() (objectformattertxtfrm.cxx:328)
   by 0x41AF924A: SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (objectformatter.cxx:191)
   by 0x41ADC213: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1633)
   by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760)
   by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351)
   by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133)
   by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711)

Change-Id: I656cc2303eeccd5eef68ad3b8e81bb0fd47b94fb

The bugdoc has a single 1-column section from start to end, no
footnotes but lots of endnotes, and the section has the settings
"Footnotes - collect at end of text" unchecked and "Endnotes - collect
at end of section" checked.

This means that the SwFootnoteContFrame for footnotes would be put
directly below the SwPageFrame (so that multiple sections on a single
page can share it), but the SwFootnoteContFrame for the endnotes is
put below the SwColumnFrame (which is created despite only 1 column)
below the SwSectionFrame.

Hence content in endnotes has the mbInfSct flag set, and the crash
happens because the endnotes are moved from below the SwSectionFrame to
a new SwFootnoteContFrame that is directly below a SwPageFrame, without
clearing the mbInfSct flag.

Fix the wrong call in SwFootnoteBossFrame::MoveFootnotes_() to
FindFootnoteBossFrame() that resulted in the wrong (unsuitable for
endnotes) SwFootnoteContFrame to be used as the target for the move.

Change-Id: I64f6b86441e5ac1f16433f005e97c274a1c69dfa