As it causes "unopkg.bin:
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/comphelper/source/misc/threadpool.cxx:96:
comphelper::ThreadPool::~ThreadPool(): Assertion `mbTerminate' failed."
in
<https://ci.libreoffice.org/job/lo_gerrit/8283/Config=linux_clang_dbgutil_64/console>
and also locally. Revert till it's clear if that assert() should be a
SAL_WARN() or unopkg has to be fixed.
This reverts commit 9899ffd244.
Change-Id: I72902f7da410012340aa8231d84c6871a3f7b976
Commit aa68c99d88 added some code using
std::condition_variable to comphelper.
Built with MSVC 2017, this causes many cppunittester.exe processes to
deadlock in ThreadPool::shutdown():
maTasksChanged.notify_all();
This ultimately calls NtReleaseKeyedEvent(), which never returns.
The reason appears to be a bug in Windows 7, for which a "hotfix"[1] is
avaiable here, but it's apparently not distributed via Windows Update
so we likely can't rely on users or even developers having this installed.
However, the documentation of DllMain[2] and ExitProcess[3] indicates
that during shutdown, by the time global destructors are invoked
all threads other than the one that called ExitProcess have already
been terminated.
Returning from main() implicitly calls ExitProcess [4].
As it turns out the problem only happens for some CppUnitTests because
soffice.bin will call ThreadPool::shutdown() from Desktop::doShutdown()
while it is still safe.
[1] http://support.microsoft.com/kb/2582203
[2] https://msdn.microsoft.com/en-US/library/windows/desktop/ms682583(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx
[4] https://blogs.msdn.microsoft.com/oldnewthing/20100827-00/?p=13023
Change-Id: I6137461ca7efe9a5fbe4f8f8478fb96de3570469
Reviewed-on: https://gerrit.libreoffice.org/35066
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Bunch of these were setting C++ or Make modes and icky tabs...
Also, reportedly Emacs can figure out to enable python-mode
automatically.
Change-Id: I50072488fb92cb4d27aa3f74f717a28ae3967543
The PythonTest_dbaccess_python may fail in incremental builds because of
stale JVM path in workdir/unittest/user/config/javasettings_Linux_X86_64.xml
so it's better to use the fresh UserInstallation that is already passed
in from PythonTest.mk. To make that work, tolerate non-existing path in
SubstitutePathVariables::SetPredefinedPathVariables() at least when
running in the build environment, which is probably better than
effectively running with "/" as UserInstallation anyway...
This partially reverts commit 6dbb6275eb.
Change-Id: I4d42d53c049056590662828360c4ce5a29af0f4b
Thanks to Stephan for helping with the test environment setup:
sbergman@redhat.com: Do the same "set UserInstallation to user profile dir in
test/user-template" in UnoInProcess's setUp as is done in
test::BootstrapFixtureBase::setUp (unotest/source/cpp/bootstrapfixturebase.cxx)
for CppunitTests. That way, these tests all use the workdir/unittest/
UserInstallation concurrently, but they at least do not run into the gotcha in
SubstitutePathVariables::SetPredefinedPathVariables
(framework/source/services/substitutepathvars.cxx) to only set the
PREDEFVAR_USERPATH if PATH_EXISTS.
Change-Id: Iad058098a4c69cb567e2d3222af3c7d4ba993271
This is nice to make them more easily debuggable.
A series of crude hacks are employed to bootstrap enough services from
python so the current tests run.
This is only tested with system python3 on Fedora.
Change-Id: I5e06741e55ead7fddec41ff776ff8ca5d2399469
Reviewed-on: https://gerrit.libreoffice.org/3215
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Extract boostraping code from convwatch.py to unotest.py. Use python builtin
unittest module as unit test framework. Specify the unit test modules in make
file. Another option would be to use discover mode of unittest module.
Add __pycache__ to global .gitignore to keep the source directory clean.
Another option would be to deliver the unit tests to workdir prior to test
execution.
Currently only system python3 is supported.
Change-Id: I2692817673f786e950e1176a17c7675f989755b6
Reviewed-on: https://gerrit.libreoffice.org/3214
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Michael Stahl