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

fixes CVE-2017-9233 and CVE-2016-9063

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

Change-Id: Ia93ec62863d16d3cc60878968b79ed0ccc5fba9b

Change-Id: I627abfe33e9c2fc4243276706c1624ce19943678

Change-Id: Ia59a1f00203fbbaad6df460c7cba4a984e206a1c

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

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

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

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

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

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

Change-Id: I9343616352489205d606043fb773185f3784a8d9
Reviewed-on: https://gerrit.libreoffice.org/39051Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>

Change-Id: Ib90f1f7def6de05144bf8215a97a6d6e15207b88
Reviewed-on: https://gerrit.libreoffice.org/39073Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Project: dictionaries  93db4f58c3b2e43003c49d33ce203bdcc8db0b93

tdf#108439: update Scottish Gaelic dictionary to 3.3

Change-Id: Id08f755bd6e4001d91a5c6129c0d07522d9cefec
Reviewed-on: https://gerrit.libreoffice.org/38985Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>

... to the columns queried, not just when entering an mdds node. Otherwise it
would return an unexpected index, plus bailing out early spares unnecessary
comparisons for the rest of a node block.

Regression of

    commit 3fed1662
    Date:   Fri Aug 16 16:29:38 2013 +0200

that started to use

    commit 7334f8db
    Date:   Fri Aug 16 16:29:27 2013 +0200

with its bad implementation.

Just that VLOOKUP on a matrix with a larger block of same typed data as the
query *and* a match in an excess column seems to be rare..

Change-Id: Ia4ef3fd56490de82910d5aa13a84be2de851f9b0

regression from...

commit e4e4d571
Date:   Wed May 31 15:40:25 2017 +0200

    clang-tidy readability-delete-null-pointer

    which in turn triggered some loplugin:useuniqueptr

lets revert the fix of

commit 93a288bd
Date:   Mon Jun 12 21:44:57 2017 +0200

    svx: fix the std::unique_ptr that deletes itself twice

and make the code do exactly like it always did pre initial change

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

Change-Id: I3e36b22cefba4c6195bcf8b85b3f7a2cc101b845

Change-Id: I6b18865913492d41a8e0206a430e267fe78c553a

Sadly we only know whether its a OpenPGP or X509 signature during
parsing, so we need to switch the implementation mid-way

Change-Id: Ib48a9da0105de62cfecda095df8c154b59ba8c40

Change-Id: I1beb692b9a9a34b5f0cf743ba9e4a145ac582184

Change-Id: Ic10846cb87e23ca9ffa0eb0d64c56fcf79c73a9d

Change-Id: Ifa43fa735c8b0d58ff3d3deca2ad4eca6560494a

Change-Id: Ia560869ec02fca7fe4219136e1fe939e13f1e4c2

Change-Id: I0308d586344b5e52ad327f6650b62ac0eac7ecb9

Change-Id: I57ae79f7632885bf5c5aadcad3fb5ad4a5a9413d

Change-Id: I423bef41f93af9d1b78ee9795be7ec33c3c7ae0c

Change-Id: I84e4d6872aab27f5b11ec727787a2eab80ef6a66

Change-Id: Iec7ca4e37d6f5c4f63aaa22acfa0bdd395747471

Change-Id: I79c132e717a62c6274eeafe33d732616cbd6a5a6