https://bugs.documentfoundation.org/show_bug.cgi?id=174231
Bug ID: 174231
Summary: Writer aborts (SIGABRT) from
Scheduler::CallbackTaskScheduling when a selected form
control's model throws in SwFEShell::GetObjCntType
during the clipboard state update
Product: LibreOffice
Version: 7.3.7.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Description:
Writer aborts with signal 6 during an idle state update, some time after a
document containing a form control is loaded and a copy of it saved. No user
action is involved at the moment of the crash. The backtrace shows the abort
coming from the scheduler's catch-all around task invocation:
Scheduler::CallbackTaskScheduling
... (idle task: state update)
SwBaseShell::StateClpbrd
SwTransferable::GetSotDestination
SwFEShell::GetObjCntTypeOfSelection
-> std::abort() (signal 6)
The code path (unchanged on master as of 2026-10-29):
1. sw/source/uibase/shells/basesh.cxx, SwBaseShell::StateClpbrd: for SID_PASTE
it calls GetView().IsPasteAllowed().
2. sw/source/uibase/uiview/view.cxx, SwView::IsPasteAllowed: its first
statement is SwTransferable::GetSotDestination(*m_pWrtShell), on every state
query, whatever the clipboard holds.
3. sw/source/uibase/dochdl/swdtflvr.cxx, SwTransferable::GetSotDestination:
calls rSh.GetObjCntTypeOfSelection().
4. sw/source/core/frmedt/fefly1.cxx, GetObjCntTypeOfSelection: calls
GetObjCntType(*pObj) for each marked object.
5. fefly1.cxx, SwFEShell::GetObjCntType(SdrObject&), the SdrInventor::FmForm
branch, with no try/catch: xSet->getPropertySetInfo(),
xInfo->hasPropertyByName("ButtonType"), xSet->getPropertyValue("ButtonType")
and *o3tl::doAccess<form::FormButtonType>(aVal). Any of these can throw: a
disposed or partly initialised control model, or a value that isn't a
FormButtonType.
6. vcl/source/app/scheduler.cxx, Scheduler::CallbackTaskScheduling: "Current
policy is that scheduler tasks aren't allowed to throw an exception"; every
catch around pTask->Invoke() (css::uno::Exception, std::exception, ...) calls
std::abort().
So an exception from a selected form control's model during an ordinary idle
state update terminates Writer. A null xSet (the UNO_QUERY failing) would be a
separate null dereference in the same place.
Suggested fix in SwFEShell::GetObjCntType: check xSet.is() and xInfo.is(), read
the value with >>= instead of o3tl::doAccess, and wrap the FmForm branch in try
{ ... } catch (const uno::Exception&) { TOOLS_WARN_EXCEPTION("sw.core", ...);
}, keeping OBJCNT_CONTROL on failure. SwView::IsPasteAllowed calling
GetSotDestination on every state query also makes this path run on every idle
update while a control is selected.
Steps to Reproduce:
1. Start Writer with a new empty document (fresh user profile), driven over
UNO.
2. Load a .docx containing a form control into that existing window, and select
the control.
3. Save a copy of the document to another path (XStorable::storeToURL).
4. Leave Writer idle with the control selected.
Actual Results:
About 70 seconds after the save, Writer aborted with signal 6 from
Scheduler::CallbackTaskScheduling, with the backtrace in the description.
Unsaved work was lost. It happened once; two further attempts with the same
steps (one also disposing a selected control's model and reselecting it) did
not abort, so the exception that escaped is not known: the core's backtrace has
no exception text.
Expected Results:
A failure to read a selected control's ButtonType during an idle state update
is caught and logged, the control is treated as a plain control
(OBJCNT_CONTROL), and Writer keeps running.
Reproducible: Sometimes
User Profile Reset: No
Additional Info:
Version: 7.3.7.2 (Ubuntu package 1:7.3.7-0ubuntu0.22.04.13)
OS: Ubuntu 22.04, x86-64; VCL: gtk3
User profile: freshly created for the session
The defective code (SwFEShell::GetObjCntType's FmForm branch) and the
scheduler's std::abort policy are both unchanged on master as of 2026-10-29.
--
You are receiving this mail because:
You are the assignee for the bug.
