On a particular system, I see unit tests reliably hung at the exit time
(at a DLL unload), when it waits indefinitely in notify_all. It is the
only thread in the process left; TimerManager thread was likely killed
by that time.
This is the call stack of the hung state:
ntdll.dll!ZwReleaseKeyedEvent()
ntdll.dll!string "Enabling heap debug options\n"()
msvcp140d.dll!Concurrency::details::stl_condition_variable_win7::notify_all() Line 178
msvcp140d.dll!_Cnd_broadcast(_Cnd_internal_imp_t * cond) Line 93
salhelper3MSC.dll!std::condition_variable::notify_all() Line 590
salhelper3MSC.dll!salhelper::TimerManager::~TimerManager() Line 221
salhelper3MSC.dll!``anonymous namespace'::getTimerManager'::`2'::`dynamic atexit destructor for 'aManager''()
ucrtbased.dll!_execute_onexit_table::__l2::<lambda>() Line 206
ucrtbased.dll!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) &,void <lambda>(void)>(__acrt_lock_and_call::__l2::void <lambda>(void) && setup, _execute_onexit_table::__l2::int <lambda>(void) & action, __acrt_lock_and_call::__l2::void <lambda>(void) && cleanup) Line 204
ucrtbased.dll!__acrt_lock_and_call<int <lambda>(void)>(const __acrt_lock_id lock_id, _execute_onexit_table::__l2::int <lambda>(void) && action) Line 974
ucrtbased.dll!_execute_onexit_table(_onexit_table_t * table) Line 231
salhelper3MSC.dll!__scrt_dllmain_uninitialize_c() Line 399
salhelper3MSC.dll!dllmain_crt_process_detach(const bool is_terminating) Line 182
salhelper3MSC.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 220
salhelper3MSC.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 293
salhelper3MSC.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 335
ntdll.dll!LdrShutdownProcess()
ntdll.dll!RtlExitUserProcess()
ucrtbased.dll!exit_or_terminate_process(const unsigned int return_code) Line 144
ucrtbased.dll!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 280
ucrtbased.dll!exit(int return_code) Line 294
cppunittester.exe!__scrt_common_main_seh() Line 297
cppunittester.exe!__scrt_common_main() Line 331
cppunittester.exe!mainCRTStartup(void * __formal) Line 17
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
This check prevents that hang.
The behavior is *possibly* related to my commit
8a0c43fa86 (Use _beginthreadex instead of
CreateThread, 2023-08-09), which put the threads under control of CRT;
and also to the specific version of CRT on the affected system, which
might affect the order of statics destruction and thread termination.
Change-Id: I6da95ea369ac9433a426a12d62cbd2a09cb4ce4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172093
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...that had been added with f90c68316c "WASM: add
Emscripten demo application". Whatever the original intention, it has probably
served its purpose by now---and now only negatively impacts (re-)build times.
Change-Id: I2bda8d12b91e741c4d0f7d3f02597e0e9505a73a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172087
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
See commit a8d677035a (Make sure to
anti-alias fonts on Windows, when required, 2024-08-19).
Change-Id: I67f863b61002da883a91ca09aa432162985c755b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172042
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit 68818db0ec (build a
IDWriteFontCollection1 of our FR_PRIVATE fonts, 2022-01-11) used
dwrite_3.h, which has API available only starting from Windows 10.
For pre-Windows 10 versions, there is a different way to implement
this, as explained at
https://learn.microsoft.com/en-us/windows/win32/directwrite/custom-font-collections
This change implements that more complex way as a fallback, until
we bump the baseline. Allows to not fall back to gdi in Skia, like
with the original commit, just on older Windows versions.
Change-Id: Ieca13e4a04bc72ce877ab9b512c7821d5466cb70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172090
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
after 3a961b522a
"sw: use SAL_RET_MAYBENULL in GetTableBox()"
Kudos to M. Stahl for flagging it
Change-Id: I44879da9206a1c04869b22c7a7b3bb18955f1953
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172052
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
These are toolbar items, and not GtkToggleButton's so use the toolbar
api here instead.
The "ToolbarUnoDispatcher" thing is to auto dispatch uno:whatver when
the toolbar items have names like that, these ones have custom handlers
so that doens't really fit here.
Change-Id: I93fc11bf364ba7ae145ff52bc78a1544c9bae412
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172047
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
which shaves 5% off the load time.
I suspect this is a copy/paste of the similar logic in
DomainMapper_Impl::PushPageHeaderFooter
where it says
// Set both sharing left and first to off so we can import the content
regardless tha what value
// the "titlePage" or "evenAndOdd" flags are set (which decide what
the sharing is set to in the document)
I suspect that
commit 4b0fa253a4
Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Date: Tue Nov 28 13:46:21 2023 +0900
tdf#136472 adjust ooxml import to handle first header/footer
sufficiently cleaned up the header/footer handling that this is no
longer necessary.
Change-Id: I05145c0f3706bd100dc200a949b9a05a1600d370
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172038
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Update helpcontent2 from branch 'master'
to 709b64df4d40a4972dea43511be7faef204e443f
- Add Help page on Sidebar settings
Note: Some entries are not mapped because it has not help ID.
"reset to default" omitted but can be added depending on
https://gerrit.libreoffice.org/c/core/+/171906
Change-Id: Ie8754e58deb76e95b2a366e1e7f4d712d3983694
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/171913
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Tested-by: Jenkins
there is a MultiSalLayout::InitFont that overrides it, but only forwards
InitFont to the first child sub SalLayout, which itself then doesn't do
anything.
This is possibly the case since:
commit 6c436ba09c
Date: Thu Dec 1 03:33:30 2016 +0200
Kill old Windows layout engines
Change-Id: Ic0d347843257d13ee6d6f695488bd053f5a931fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172040
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
GetUseFontAAFromSystem was introduced to make sure that texts in generated
raster file match the requested antialiasing selection, not system display
settings (VCL plugins usually render text according to system settings for
screen display, even when lines are not anti-aliased). The use case there
was disabling antialiasing, to produce clear output in tests - see commit
e6538f5bdd tdf#118966 vcl: add a flag to
determine if AA of fonts is used from the system, 2018-07-28.
But the opposite case is also valid: bitmap file export with antialiasing
must smooth text, even when system display antialiasing is disabled. This
has hit testTdf162259 on a particular buildbot, where the output happened
to be black-and-while (see commit 7a08c89b5a
Workaround a non-antialiased output on one of Windows buildbots, 2024-08-17).
The problem turned out to be RDP settings used to connect that particular
buildbot, which happened to disable AA. This basically means that output
of '--convert-to png' would depend on the system where it's called.
This change extends the effect of GetUseFontAAFromSystem to not only force
disabled text AA, when it returns false and line AA is disabled, but also
force enabled text AA, when it returns false and line AA is enabled. This
is a Windows-only change. I will change the test to use this in a separate
commit.
Change-Id: I7071f1bdefb77cbb9156dde3f70feb4cf8be73f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172031
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Calc ignored the firstHeaderRow attibute on xlsx pivot tables causing
it to add an extra row when firstHeaderRow="0". And then changed the
value to "1" on export.
Some xlsx pivot table filter tests have been changed because removing
this extra row changed the position of the values.
Change-Id: I95b722e4f4cc40083c752a045df4ffe37e7159c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171836
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171869
Tested-by: Jenkins
At least when LO tries to download a document and
UUIInteractionHelper::handleErrorHandlerRequest wants to show a MessageDialog
via Qt, the stack grows relatively large, and gray_convert_glyph
(workdir/UnpackedTarball/freetype/src/smooth/ftgrays.c) alone allocates on the
stack a buffer of size FT_MAX_GRAY_POOL * sizeof(TCell) = 1024 * 16 = 16K, which
causes (silent, due to no -sSTACK_OVERFLOW_CHECK=2) stack overflow.
So (somewhat randomly) double the size of the main thread stack to 128K; but, at
least for now, keep the default value of 64K for other threads (which would
otherwise inherit the explicitly set -sSTACK_SIZE value via the
-sDEFUALT_PTHREAD_STACK_SIZE=0 default).
Change-Id: I96583f4af93c84b15c67f310068c5631fb129d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172011
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...after 6e6451ce96 "Emscripten: Move the Qt event
loop off the JS main thread"
Change-Id: Iea9cb74fa2fc3dd036ee865e1bd8ede93fb33c78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172010
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
An omission from commit 8484e52675
"tdf#117427 missing API for determining and loading linked graphic",
2018-05-12, that introduced it.
Change-Id: Ibf4c754931f813c5234daa5f7b7c907ed84efdef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172008
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...before disappearing through the QApplication::exec() hole, or else the
SolarMutex would remain locked forever on the application's main thread.
This requires changing SalInstance::ReleaseYieldMutexAll() to
SalInstance::ReleaseYieldMutex(bool all). (Further recursive locking of the
SolarMutex via SolarMutexGuard instances that would be present on the call stack
leading up to the call to QApplication::exec() would be released during the
stack unwinding, so just undo the one acquiring done in InitVCL, not all of
them.)
Change-Id: I9ef57abb7da7f840999700e4eaeeefd2da784645
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171956
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
