Change-Id: I69b105c39f67372331910b6957214d62e1f3818c

Change-Id: Ib3d3e5b57799c22916845899839ddcc9a81e9b98

nStopPos is non-inclusive, and STL's erase() method also expects a
non-inclusive end position (like any other STL methods do).  It's wrong
to -1 here which would end up not erasing the last element containing
a pointer to the deleted cell instance.

Change-Id: Ia3ef4469b50695038836ff7b9b48172256032786

Treat as if this flag is always false.

Change-Id: Ie1364ac54f95263aa316bf81f631e607843934d5

  SCROW nRow = maItems[i].nRow;

and nRow will never be modified afterwards.  So

  if (nRow != maItems[i].nRow)

is never true.

Change-Id: I4f867a704d50138aee8c5e7f37464880470098c2

Change-Id: I028606c41b1486349f96b62e0ddb071ad46e9e55

Change-Id: If4edbe6fdb56e4b8fd8545404267dea7009a8c7a

Since we don't use inc / dec recalc level, we need to do this.

Change-Id: Ia99b4dbfceefd1ed951a61374250c5c61e39a62a

That scheme made it extremely hard to determine when the object's
positions get recalculated.  It's better to figure out when to recalc
drawing objects' positions, and call SetDrawPageSize() manually at
that point (and only once!)

Change-Id: I05d9b693cfc9310f5472ed8287c7a2e36646f4d7

for cell storage in column.  And std::vector internally does double allocation.

Change-Id: I4363e7593def3feb71100487c7f88c05797596e7

Don't even try to build --enable-headless where GUIBASE would not
be unx.

Change-Id: I6e5a6d3071317171f42c0b1336502cec50ba72fa

Change-Id: Ic58a5503dc6b7991c8804feef05b814d1055bfb9

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

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

Change-Id: I1079cf87d223fc03e8cef53f69fa76ea4386c9b8

Change-Id: I729612b2ffeea9c3c64f8f0c0c2313f48b965270

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

Apply mmeeks temporary solution until a proper fix is found. With the patch
applied unoconv testsuite runs fine.

mmeeks analysis of the problem:

    It looks really interesting :-) it's hard to tell (from valgrind) where
the threads were pre-empted [ actually logging that might be quite a
nice feature to add to for valgrind ;-], but there is already the
SolarMutex guard to try to stop this from happening.

    I append the odd trace with some thoughts.

    It is -possible- that we never get around to taking the solar mutex in
the first instance in 'main' - such that by the time we come to release
and re-take it in vcl/headless/svpinst.cxx:

void SvpSalInstance::Yield( bool bWait, bool bHandleAllCurrentEvents )

    the count is zero - could you add some fprintf debugging to check that
- just dump nAcquireCount

==28574== Thread 1:
==28574== Invalid read of size 8
==28574==    at 0x739C702: SfxStateCache::SetState_Impl(unsigned short, SfxPoolItem const*, unsigned char) (statcach.cxx:454)
==28574==    by 0x738042E: SfxBindings::UpdateControllers_Impl(SfxInterface const*, SfxFoundCache_Impl const*, SfxPoolItem const*, unsigned short) (bindings.cxx:1500)
==28574==    by 0x7383C5B: SfxBindings::Update_Impl(SfxStateCache*) (bindings.cxx:437)
==28574==    by 0x7383FD7: SfxBindings::NextJob_Impl(Timer*) (bindings.cxx:1646)
==28574==    by 0x92BF4AD: Timer::ImplTimerCallbackProc() (timer.cxx:142)

    The YieldMutex -should- be held at this point excluding this other thread (?).

==28574==    by 0x95D152D: SvpSalInstance::CheckTimeout(bool) (saltimer.hxx:57)
==28574==    by 0x95D17D7: SvpSalInstance::Yield(bool, bool) (svpinst.cxx:288)
==28574==    by 0x92B4530: Application::Yield(bool) (svapp.cxx:434)
==28574==    by 0x92B45E6: Application::Execute() (svapp.cxx:413)
==28574==    by 0x50AED58: desktop::Desktop::Main() (app.cxx:1711)
==28574==    by 0x92BDFB8: ImplSVMain() (svmain.cxx:173)
==28574==    by 0x92BE8E4: SVMain() (svmain.cxx:210)
==28574==    by 0x50E1CF4: soffice_main (sofficemain.cxx:83)
==28574==    by 0x40069A: main (main.c:25)

==28574==  Address 0x1466bdc8 is 56 bytes inside a block of size 72 free'd
==28574==    at 0x4C27FF2: operator delete(void*) (vg_replace_malloc.c:387)
==28574==    by 0x737F479: SfxBindings::DeleteControllers_Impl() (bindings.cxx:325)
==28574==    by 0x7380572: SfxBindings::~SfxBindings() (bindings.cxx:264)
==28574==    by 0x7380718: SfxBindings::~SfxBindings() (bindings.cxx:275)
==28574==    by 0x758B91E: SfxFrame::DoClose_Impl() (frame.cxx:178)
==28574==    by 0x75AAFC1: SfxBaseController::dispose() (sfxbasecontroller.cxx:1041)

sfx2/source/view/sfxbasecontroller.cxx:

    This method has a live:

            SolarMutexGuard aGuard;

==28574==    by 0x16B8E785: framework::Frame::setComponent(com::sun::star::uno::Reference<com::sun::star::awt::XWindow>  const&, com::sun::star::uno::Reference<com::sun::star::frame::XController>  const&) (frame.cxx:1380)
==28574==    by 0x16B8E1CF: framework::Frame::close(unsigned char) (frame.cxx:1633)
==28574==    by 0x758BE87: SfxFrame::DoClose() (frame.cxx:140)
==28574==    by 0x797F51C: SfxBroadcaster::Broadcast(SfxHint const&) (brdcst.cxx:49)
==28574==    by 0x7511211: SfxModelListener_Impl::notifyClosing(com::sun::star::lang::EventObject const&) (objxtor.cxx:173)
==28574==    by 0x7534972: SfxBaseModel::close(unsigned char) (sfxbasemodel.cxx:1491)
==28574==    by 0x1E776909: SwXTextDocument::close(unsigned char) (unotxdoc.cxx:578)
==28574==    by 0x7537FB0: SfxBaseModel::dispose() (sfxbasemodel.cxx:788)
==28574==    by 0x1211D6E7: gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, unsigned int, double*, unsigned int) (callvirtualmethod.cxx:128)
==28574==    by 0x12120FEE: cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) (uno2cpp.cxx:246)
==28574==    by 0x12121ACD: bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) (uno2cpp.cxx:440)
==28574==    by 0x15D5CE5E: binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny>  >*) const (incomingrequest.cxx:251)
==28574==    by 0x15D5D8AB: binaryurp::IncomingRequest::execute() const (incomingrequest.cxx:80)
==28574==    by 0x15D61B4C: request (reader.cxx:89)
==28574==    by 0x663A506: cppu_threadpool::JobQueue::enter(long, unsigned char) (jobqueue.cxx:115)
==28574==    by 0x663B00D: cppu_threadpool::ORequestThread::run() (thread.cxx:179)
==28574==    by 0x663B4E9: threadFunc (thread.hxx:196)
==28574==    by 0x4E467AE: osl_thread_start_Impl (thread.c:261)
==28574==    by 0x5E53EFB: start_thread (pthread_create.c:304)
==28574==    by 0x5B8E89C: clone (clone.S:112)

Change-Id: I84aea49aff1dbc6c0d34e522d57d5af90eebfc62

aae8a0c8 with rather unhelpful
"#99188# enlarge textrect to get rid of rounding problems" comment
appears to be the root. Lets assume that commit is necessary and
just adjust alternatively for right align

Change-Id: I0b60c12199226ca757596c034599b81c1a4db433

Change-Id: Ie5068b45520b6c82af41062d97ec65d006b4b3ba

After having talked about on IRC with Michael Meeks, it seems UX team prefers that way.
In brief, it was on purpose. Thank you Michael for your time

Change-Id: Ib99425a212ac5463b0465e1e755e2537bb4d51b8

Change-Id: I67259c5a3894be406b2d38900368a3f8aac86921
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>

Change-Id: Ic13269fcf55b4e51a8124da6d2de75fb5bec23e0

Change-Id: I5f7dc2a389c020a90b8087aefc90c054a809ef25

that are needed to load .odt, .sxw etc files, and
add a regression test for CVE-2012-4233

Change-Id: Ie178725ded3d76942030d12f23074de519cf62de

Change-Id: Iea7d8681cdcd45d545826af63fc689640dfe29f0

Change-Id: I7b59ddc4f9170c33e948f30194a662f27b871fcc

In an MSVC build, not exporting BUILD_OPT to the Mozilla build
machinery causes the produced DLLs to use the debug CRT. The exact
mechanism is a bit of a mystery, and I didn't feel like spending too
much time trying to understand it.

Using the debug CRT is confusing and wrong. Nothing in LO otherwise
uses it. It also makes testing a build much harder for me at least, as
I do that in a fairly pristine virtual machine with no MSVC debugging
runtime available. (The normal CRT is bundled in the LO installer.)

Change-Id: I27f774d92a3986d40162c870202bcdddd94aa7c6

Change-Id: Ifd59198a2d09e26377267c8b509c5340d83240e3

Change-Id: I6223cd12ab539cd19555c0b23f2bce73f519a31f

I always wanted to do this.  The new name reflects what it really does
better than the old one.

Change-Id: I3c90cce06d482f1453936ff3916eef9663bb417b

Change-Id: Idd3ca250ea51c9e17b4566febf13d9c8ca9c6a8f

There is no point of having hasCache() method which always returns true.

Change-Id: I309d3c33899cdab2049af5199ae8d41f7cbd5f99

They were correct up until IBM re-worked a whole bunch of stuff during
the OOo 3.2 (?) development cycle.

Change-Id: Ia9a9e30287f6c8451a6cfa98f3515d703e3c67cc

Change-Id: I10f8d534d664c5f27a32214c00aeee890d993d18

Perhaps this will make valgrind happy?

Change-Id: I11f965d13f8d71b2ab9f9624367fd70713644f10

Change-Id: Iae3eceb38a6f9bc53805445799534ec8ee44a9a9

Change-Id: I20bbd2d5ed7ba3c84ee33544f4a1a39c02729c23

When removing an entry from the tree list, we need to

1) first remove the entry from the list,
2) broadcast its removal with the entry instance, then
3) finally delete the entry itself at the very end.

in this exact order, or else interesting stuff would ensue.

Change-Id: If42b141921ffe4ed36dce31f93a4a084204815bf

Change-Id: I48cd5988056c8dee10241d5ba3b469ae7e5191b9