https://bugs.documentfoundation.org/show_bug.cgi?id=173676
Bug ID: 173676
Summary: Crash (null deref) in
sfx2::sidebar::SidebarController::UpdateConfigurations
() in a headless UNO document conversion service
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: framework
Assignee: [email protected]
Reporter: [email protected]
Description:
We run several headless LibreOffice instances as a DOCX -> PDF conversion
service on
Windows Server 2022. Each worker is started as:
soffice.exe -env:UserInstallation=file:///<per-worker dir> --invisible
--headless
--norestore --nologo --nodefault --nolockcheck --nocrashreport
--nofirststartwizard
--accept=socket,host=localhost,port=<N>,tcpNoDelay=1;urp;StarOffice.Service
A client connects over URP for each conversion and calls
loadComponentFromURL(Hidden=true, ReadOnly=true),
storeToURL(FilterName=writer_pdf_Export)
and close(true).
Under sustained load soffice.bin terminates. The client observes
com.sun.star.lang.DisposedException / SocketException: Connection reset at the
close(true)
call, because the peer process is already gone.
ROOT CAUSE (from two complete minidumps, identical in both):
Original exception: ACCESS_VIOLATION (0xC0000005), read of address 0x128 (null
pointer
plus member offset).
#00 std::vector<std::unique_ptr<sfx2::sidebar::TabBar::Item>>::clear + 0x18
#01 sfx2::sidebar::SidebarController::UpdateConfigurations() + 0x2ea
#02 sfx2::sidebar::AsynchronousCall::HandleUserCall + 0xc0
#03 ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) + 0x9fc
#04 SalFrame::CallCallback(SalEvent, void const*) + 0x1c
#05 vclplug_winlo!SalFrameWndProcW + 0x4d
#06 user32!<window procedure dispatch>
The exception escapes the window procedure, so Windows invokes the unhandled
exception
filter, which LibreOffice handles as follows:
KERNELBASE!UnhandledExceptionFilter + 0x1bd
sal3!<signal handler> + 0xaf
desktop::Desktop::Exception(ExceptionCategory) + 0x13c
SalAbort(rtl::OUString const&, bool) + 0x64
KERNELBASE!RaiseException + 0x6c (RaiseException(0,
EXCEPTION_NONCONTINUABLE, 0, NULL))
Because of that last step every crash is reported by WER as
"Exception code: 0x00000000, Faulting module KERNELBASE.dll, Fault offset
0x3f46c",
which hides the real cause. One event out of 229 surfaced the underlying
0xC000041D (STATUS_FATAL_USER_CALLBACK_EXCEPTION), consistent with an exception
escaping a window procedure.
Two observations that may help:
- The sidebar controller is alive at all in a --headless --invisible process
whose
documents are all loaded with Hidden=true. It is not clear why the sidebar
is
instantiated for such frames.
- The crash arrives through the window procedure of the hidden frame. With
four
worker processes on one machine, 89% of the crashes happen in clusters of
2-4
processes within <= 3 seconds (48 clusters took out all four at once,
sometimes
within 20 ms), which suggests a system-wide or broadcast window message
reaching
all hidden frames simultaneously.
STATISTICS from 3 test runs (about 27 hours, 4 workers):
- 396 process deaths
- in 325 of them (82%) the process was already gone when our supervisor went
to
terminate it, i.e. LibreOffice died on its own
- dying processes were between 6 s and 4 h old, so it is not age- or
usage-related
- every retry on a freshly started process succeeded; no document reproduces
it
deterministically
- frequency rises with load, roughly one crash per 100-200 conversions
MINI DUMP:
https://drive.google.com/file/d/1IQNJQv02H45I7LRk-MsuuBWpafwNoZ5E/view?usp=sharing
Steps to Reproduce:
1.run several headless LibreOffice instances as a DOCX -> PDF conversion
service on Windows Server 2022
soffice.exe -env:UserInstallation=file:///<per-worker dir> --invisible
--headless
--norestore --nologo --nodefault --nolockcheck --nocrashreport
--nofirststartwizard
--accept=socket,host=localhost,port=<N>,tcpNoDelay=1;urp;StarOffice.Service
2.client connects over URP for each conversion and calls:
- loadComponentFromURL(Hidden=true, ReadOnly=true)
- storeToURL(FilterName=writer_pdf_Export)
- close(true)
3.Under sustained load soffice.bin terminates. The client observes
com.sun.star.lang.DisposedException / SocketException: Connection reset at the
close(true) call, because the peer process is already gone.
Actual Results:
Under sustained load soffice.bin terminates. The client observes
com.sun.star.lang.DisposedException / SocketException: Connection reset at the
close(true) call, because the peer process is already gone
Expected Results:
soffice.bin keeps serving URP requests; the sidebar controller must not
dereference a null pointer, and an exception must not escape the window
procedure.
Reproducible: Always
User Profile Reset: No
Additional Info:
Version 26.8.0.3, build bce0998afefdbc355585ca324285661a2170ba77, x86-64,
installed from
the official MSI via an administrative install (msiexec /a). The previous
version (25.2.7.2) works correctly and does not exhibit this behavior.
Ruled out: not memory exhaustion (~220-240 MB per process after 40
conversions); not
OpenCL (Common/Misc/UseOpenCL is false at runtime, verified over UNO); not Skia
(A/B with
VCL/UseSkia=false and with SAL_DISABLESKIA=1, 3 parallel processes x 40
conversions each,
0 failures in both arms; UseSkia=true is the Windows default and was already so
in
25.2.7.2); not GDI exhaustion (57 GDI objects per process).
We found no configuration setting that disables the sidebar, so we have no
workaround on
our side.
MINI DUMP:
https://drive.google.com/file/d/1IQNJQv02H45I7LRk-MsuuBWpafwNoZ5E/view?usp=sharing
--
You are receiving this mail because:
You are the assignee for the bug.
