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

Change-Id: I9bb589e8a349a1404f9c09a60a82e824918744fa

"make -jyes" considered useless

Change-Id: I044e95f76e8ea961e781e75c4b6923e700e0d375

Change-Id: I815ef8abaf4cd998e7b91fbadad56ddf0a7087ba

Change-Id: Ieba85dd0093c9f704090075d2eb75f1eefdd72de

...introduced with 75bc673b "Travelled MIME type
through UCB for CMIS UCP to use it when creating documents" and causing crashes
in sc_unoapi test.  Many SfxMedium instances appear to have a null filter, so
this workaround at least fixes the crashes.  No idea what a good fix should look
like, so will ask Cedric to review his commit.

Change-Id: I27180265b6c79c7ed5f459b03c9e188ff6a0f56d

Change-Id: I91ded7801f4959f2dac7b5b3e4c8d1f3929f4ed9

Change-Id: I8474e5da02036f065057a5610def6701db4cedc7

Change-Id: I431c0615de56ddc0fa2c0ea06567d32419d29440

Change-Id: I655e8e15c7f7a8c292b3a1820ee48c29e847d05a

Change-Id: I98aa2bcb90385096915c9cddea6a9e68ab95d29c

Change-Id: Id54d9bd2963573c4b8e77de0dfafe33ea5882d32
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/947Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

use plain copy instead of git-new-workdir when using --with-linked-git
configure switch (point it to your master copy of the core-repo)
also remove obsolete bin/create_bootstrap_links, bin/mkworkdir and
bin/repo-list[.in]

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

Change-Id: Ibb9bbf018e4e9c1487ccdf6505a2a15d7c24eb24

Project: help  eab79dba5c42eaeb6ecac4a9b6eeb0e6500f3301
update macro dialog help ids for .ui

Change-Id: Ia283f2e70fa623d0155b6de51ad5441163505cc0
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/945Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

MSVC warns about the anonymous struct, and the way we write and read
from the union is undefined.

Change-Id: I683f54d90393a744e5c94857cd87800bcc8f9ffe

These cause valgrind warnings in sc_unoapi.
(regression from d2b49b5b)

Change-Id: If3128410bfabc23ff85c24156a8602379b8b7edd