Bug 169876 - LO crashes, when form will be opened through macro when Base document had been opened.
Summary: LO crashes, when form will be opened through macro when Base document had bee...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
25.8.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:26.8.0
Keywords: bibisectRequest, regression
Depends on:
Blocks: Macro Database-Import
  Show dependency tree / graph
 
Reported: 2025-12-07 14:39 UTC by Robert Großkopf
Modified: 2026-01-08 07:23 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Open the database file under Win11 with macros enabled. (11.88 KB, application/vnd.oasis.opendocument.database)
2025-12-07 14:39 UTC, Robert Großkopf 		Details
macOS Hang screenshot on activating macros (439.45 KB, image/png)
2025-12-17 11:05 UTC, Alex Thurgood 		Details
Apple forced kill trace (3.45 MB, text/plain)
2025-12-17 11:05 UTC, Alex Thurgood 		Details
backtrace (8.68 KB, text/plain)
2025-12-24 13:15 UTC, Saburo 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2025-12-07 14:39:54 UTC 
Created attachment 204484 [details]
Open the database file under Win11 with macros enabled.

Open the attached database with macros enabled.
The (only) form of this database document tries to open but will crash the whole LO.

This buggy behavior won't appear under Linux, won't appear with older versions of LO like 25.2.7. It appears with LO 25.8.3.2 and Windows 11.

Macro has been bound to the Base document by Tools → Customize → Events → Open Document.

Note: 
Same code, but not connected to this event, will work. 
Other code, connected to this event, will work also. Only opening forms automatically won't work any more with Windows11
Comment 1 m_a_riosv 2025-12-07 23:46:56 UTC 
Reproducible even in Safe Mode
Version: 25.8.4.1 (X86_64)
Build ID: 6ab4ab096601e7cd763971a4dad5a6c7322a1a59
CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win
Locale: en-GB (es_ES); UI: en-US
Calc: threaded



Latest version that works on the ones I have installed.
Version: 25.8.2.2 (X86_64)
Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f
CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

And works with
Version: 25.8.2.2 (X86_64)
Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f
CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 2 documentfoundation.jl1rc 2025-12-09 08:28:25 UTC 
reproducible 
Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 24; OS: Windows 11 X86_64 (build 26200); UI render: default; VCL: win
Locale: de-DE (en_DE); UI: en-GB
Calc: CL threaded
Comment 3 Saburo 2025-12-10 03:02:31 UTC 
bibisected with win64-26.2
first time bad commit 7290daa1e12c5e81ed8c2909cdb6a164bfb3c478
second time bad commit 23afeaedf4d4a03943338fc39ae41f5c423e5997
***
Someone please confirm.
Comment 4 Robert Großkopf 2025-12-17 10:12:43 UTC 
(In reply to Saburo from comment #3)
> bibisected with win64-26.2
> first time bad commit 7290daa1e12c5e81ed8c2909cdb6a164bfb3c478
> second time bad commit 23afeaedf4d4a03943338fc39ae41f5c423e5997
> ***
> Someone please confirm.

Think the second ist the bad commit. The first is only an update for a library, which seems to be special for Mac.

Putting mike to cc.
Comment 5 Alex Thurgood 2025-12-17 10:59:59 UTC 
On macOS, clicking on Activate Macros when loading the ODB file causes LO to hang.

The problem doesn't appear to be just linked to running on Windows.

Mutex lock management is frequently a tricky problem within Base, so the problem may be more general than just that Windows commit.
Comment 6 Alex Thurgood 2025-12-17 11:04:54 UTC 
(In reply to Alex Thurgood from comment #5)
> On macOS, clicking on Activate Macros when loading the ODB file causes LO to
> hang.
> 
> The problem doesn't appear to be just linked to running on Windows.
> 
> Mutex lock management is frequently a tricky problem within Base, so the
> problem may be more general than just that Windows commit.

Tested on

Version: 25.8.3.2 (AARCH64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 8; OS: macOS 26.1; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

cf. attached screenshot on hang.

Forced kill is the only way out on macOS, cf. attached Apple trace.
Comment 7 Alex Thurgood 2025-12-17 11:05:21 UTC 
Created attachment 204690 [details]
macOS Hang screenshot on activating macros
Comment 8 Alex Thurgood 2025-12-17 11:05:44 UTC 
Created attachment 204691 [details]
Apple forced kill trace
Comment 9 Mike Kaganski 2025-12-17 12:13:22 UTC 
Repro using 25.8.
No repro using master (toward 26.8).
Fixed in the meanwhile?
Comment 10 Saburo 2025-12-18 05:11:29 UTC 
still in
2025-12-16
Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 680(Build:0)
CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: threaded

The frequency is not always, but it seems to be more than once in five times.
I've also had hangs when closing forms.
Comment 11 Mike Kaganski 2025-12-18 06:22:03 UTC 
Noel: on Windows, loading the bugdoc sometimes produces an assert with

> vclplug_winlo.dll!WinSalFrame::AcquireGraphics() Line 1023	C++
> vcllo.dll!vcl::WindowOutputDevice::AcquireGraphics() Line 837	C++
> vcllo.dll!OutputDevice::HasMirroredGraphics() Line 662	C++
> vcllo.dll!vcl::Window::ImplPosSizeWindow(__int64 nX, __int64 nY, __int64 nWidth, __int64 nHeight, PosSizeFlags nFlags) Line 1524	C++
> vcllo.dll!vcl::Window::setPosSizePixel(__int64 nX, __int64 nY, __int64 nWidth, __int64 nHeight, PosSizeFlags nFlags) Line 2807	C++
> vcllo.dll!DockingWindow::setPosSizePixel(__int64 nX, __int64 nY, __int64 nWidth, __int64 nHeight, PosSizeFlags nFlags) Line 829	C++
> vcllo.dll!vcl::Window::SetPosSizePixel(const Point & rNewPos, const Size & rNewSize) Line 1354	C++
> fwklo.dll!framework::ToolbarLayoutManager::implts_calcWindowPosSizeOnSingleRowColumn(long nDockingArea, long nOffset, framework::ToolbarLayoutManager::SingleRowColumnWindowData & rRowColumnWindowData, const Size & rContainerSize) Line 2541	C++
> fwklo.dll!framework::ToolbarLayoutManager::doLayout(const Size & aContainerSize) Line 229	C++
> fwklo.dll!framework::LayoutManager::implts_doLayout(bool bForceRequestBorderSpace, bool bOuterResize) Line 2323	C++
> fwklo.dll!framework::LayoutManager::implts_doLayout_notify(bool bOuterResize) Line 2212	C++
> fwklo.dll!framework::LayoutManager::unlock() Line 2195	C++
> embobj.dll!embeddedobj::DocumentHolder::GetDocFrame() Line 868	C++
> embobj.dll!embeddedobj::DocumentHolder::Show() Line 1012	C++
> embobj.dll!OCommonEmbeddedObject::SwitchStateTo_Impl(long nNextState) Line 334	C++
> embobj.dll!OCommonEmbeddedObject::changeState(long nNewState) Line 523	C++
> dbalo.dll!dbaccess::ODocumentDefinition::onCommandOpenSomething(const com::sun::star::uno::Any & _rOpenArgument, const bool _bActivate, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & _rxEnvironment) Line 933	C++
> dbalo.dll!dbaccess::ODocumentDefinition::execute(const com::sun::star::ucb::Command & aCommand, long CommandId, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & Environment) Line 997	C++
> dbalo.dll!dbaccess::ODocumentContainer::loadComponentFromURL(const rtl::OUString & _sURL, const rtl::OUString & __formal, long __formal, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & Arguments) Line 552	C++
> dbulo.dll!dbaui::OLinkedDocumentsAccess::impl_open(const rtl::OUString & _rLinkName, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> & _xDefinition, dbaui::ElementOpenMode _eOpenMode, const comphelper::NamedValueCollection & _rAdditionalArgs) Line 145	C++
> dbulo.dll!dbaui::OLinkedDocumentsAccess::open(const rtl::OUString & _rLinkName, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> & _xDefinition, dbaui::ElementOpenMode _eOpenMode, const comphelper::NamedValueCollection & _rAdditionalArgs) Line 297	C++
> dbulo.dll!dbaui::OApplicationController::openElementWithArguments(const rtl::OUString & _sName, dbaui::ElementType _eType, dbaui::ElementOpenMode _eOpenMode, unsigned short _nInstigatorCommand, const comphelper::NamedValueCollection & _rAdditionalArguments) Line 1777	C++
> dbulo.dll!dbaui::OApplicationController::loadComponentWithArguments(long ObjectType, const rtl::OUString & ObjectName, unsigned char ForEditing, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & Arguments) Line 436	C++
> dbulo.dll!dbaui::OApplicationController::loadComponent(long ObjectType, const rtl::OUString & ObjectName, unsigned char ForEditing) Line 425	C++
> dbalo.dll!dbaccess::ODocumentDefinition::impl_openUI_nolck_throw(bool _bForEditing) Line 1802	C++
> dbalo.dll!dbaccess::ODocumentDefinition::open() Line 1839	C++
> mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214	C++
> mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 430	C++
> reflectionlo.dll!stoc_corefl::`anonymous namespace'::IdlInterfaceMethodImpl::invoke(const com::sun::star::uno::Any & rObj, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & rArgs) Line 593	C++
> sblo.dll!SbUnoObject::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 2226	C++
> svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 43	C++
> sblo.dll!SbxVariable::Broadcast(SfxHintId nHintId) Line 154	C++
> sblo.dll!SbxValue::SbxValue(const SbxValue & r) Line 68	C++
> sblo.dll!SbxVariable::SbxVariable(const SbxVariable & r) Line 48	C++
> sblo.dll!SbxMethod::SbxMethod(const SbxMethod & r) Line 841	C++
> sblo.dll!SbiRuntime::FindElement(SbxObject * pObj, unsigned long nOp1, unsigned long nOp2, ErrCode nNotFound, bool bLocal, bool bStatic) Line 3700	C++
> sblo.dll!SbiRuntime::StepELEM(unsigned long nOp1, unsigned long nOp2) Line 4195	C++
> sblo.dll!SbiRuntime::Step() Line 805	C++
> sblo.dll!`anonymous namespace'::RunInitGuard::run() Line 1021	C++
> sblo.dll!SbModule::Run(SbMethod * pMeth) Line 1181	C++
> sblo.dll!SbModule::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 776	C++
> svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 43	C++
> sblo.dll!SbMethod::Broadcast(SfxHintId nHintId) Line 2116	C++
> sblo.dll!SbxValue::Get(SbxValues & rRes) Line 289	C++
> sblo.dll!SbMethod::Call(SbxValue * pRet, SbxVariable * pCaller) Line 2072	C++
> basprovlo.dll!basprov::BasicScriptImpl::invoke(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aParams, com::sun::star::uno::Sequence<short> & aOutParamIndex, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aOutParam) Line 262	C++
> protocolhandlerlo.dll!scripting_protocolhandler::ScriptProtocolHandler::dispatchWithNotification(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArgs, const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> & xListener) Line 213	C++
> protocolhandlerlo.dll!scripting_protocolhandler::ScriptProtocolHandler::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArgs) Line 286	C++
> dbalo.dll!dbaccess::`anonymous namespace'::lcl_dispatchScriptURL_throw(const unotools::WeakReference<dbaccess::ODatabaseDocument> & xWeakDocument, const com::sun::star::uno::Reference<com::sun::star::util::XURLTransformer> & xURLTransformer, const rtl::OUString & _rScriptURL, const com::sun::star::document::DocumentEvent & _rTrigger) Line 100	C++
> dbalo.dll!dbaccess::DocumentEventExecutor::documentEventOccured(const com::sun::star::document::DocumentEvent & Event) Line 169	C++
> dbalo.dll!comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::NotifySingleListener<com::sun::star::document::DocumentEvent>::operator()(const com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener> & listener) Line 252	C++
> dbalo.dll!comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::forEach<comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::NotifySingleListener<com::sun::star::document::DocumentEvent>>(const comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::NotifySingleListener<com::sun::star::document::DocumentEvent> & func) Line 278	C++
> dbalo.dll!comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::notifyEach<com::sun::star::document::DocumentEvent>(void(com::sun::star::document::XDocumentEventListener::*)(const com::sun::star::document::DocumentEvent &) NotificationMethod, const com::sun::star::document::DocumentEvent & Event) Line 293	C++
> dbalo.dll!dbaccess::DocumentEventNotifier_Impl::impl_notifyEvent_nothrow(const com::sun::star::document::DocumentEvent & _rEvent) Line 197	C++
> dbalo.dll!dbaccess::DocumentEventNotifier_Impl::processEvent(const comphelper::AnyEvent & _rEvent) Line 230	C++
> comphelper.dll!comphelper::AsyncEventNotifierBase::execute() Line 138	C++
> comphelper.dll!comphelper::AsyncEventNotifierAutoJoin::run() Line 246	C++
> comphelper.dll!threadFunc(void * param) Line 190	C++
> sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67	C++
> ucrtbased.dll!00007ff8faf32ec5()	Unknown
> kernel32.dll!BaseThreadInitThunk()	Unknown
> ntdll.dll!RtlUserThreadStart()	Unknown

It looks like sometimes WinSalFrame::ReleaseGraphics doesn't release what it is expected to release ... but in general, I don't quite understand our handling of HDCs. Could you please take a look at this at some point? Thanks!
Comment 12 Mike Kaganski 2025-12-18 12:13:41 UTC 
Hmm, I intended to write that I don't get the problem with software rendering, and then I got a crash.

I got at least three different manifestations to now, and all of them look related to HDC management.

With sw rendering, I see a crash because of unhandled exception in VCL Main thread:

> vcruntime140d.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 79	C++
> vcllo.dll!VirtualDevice::ImplInitVirDev(const OutputDevice * pOutDev, __int64 nDX, __int64 nDY, const SystemGraphicsData * pData) Line 168	C++
> vcllo.dll!VirtualDevice::VirtualDevice(const OutputDevice * pCompDev, DeviceFormat eFormatAndAlpha, OutDevType eOutDevType) Line 216	C++
> vcllo.dll!VirtualDevice::VirtualDevice(const OutputDevice & rCompDev, DeviceFormat eFormat) Line 102	C++
> vcllo.dll!VclPtr<VirtualDevice>::Create<OutputDevice &>(OutputDevice & <arg_0>) Line 143	C++
> vcllo.dll!vcl::BufferDevice::BufferDevice(const VclPtr<vcl::Window> & pWindow, OutputDevice & rRenderContext) Line 15	C++
> vcllo.dll!MenuBarWindow::Paint(OutputDevice & rRenderContext, const tools::Rectangle & __formal) Line 886	C++
> vcllo.dll!PaintHelper::DoPaint(const vcl::Region * pRegion) Line 316	C++
> vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 618	C++
> vcllo.dll!PaintHelper::~PaintHelper() Line 553	C++
> vcllo.dll!vcl::Window::ImplCallPaint(const vcl::Region * pRegion, ImplPaintFlags nPaintFlags) Line 624	C++
> vcllo.dll!vcl::Window::ImplCallOverlapPaint() Line 645	C++
> vcllo.dll!vcl::Window::ImplHandlePaintHdl(Timer * __formal) Line 668	C++
> vcllo.dll!vcl::Window::LinkStubImplHandlePaintHdl(void * instance, Timer * data) Line 649	C++
> vcllo.dll!Link<Timer *,void>::Call(Timer * data) Line 105	C++
> vcllo.dll!Timer::Invoke() Line 75	C++
> vcllo.dll!Scheduler::CallbackTaskScheduling() Line 614	C++
> vcllo.dll!SalTimer::CallCallback() Line 53	C++
> vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 169	C++
> vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 481	C++
> vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 537	C++
> vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 389	C++
> vcllo.dll!Application::Yield() Line 502	C++
> vcllo.dll!Application::Execute() Line 365	C++
> sofficeapp.dll!desktop::Desktop::Main() Line 1681	C++
> vcllo.dll!ImplSVMain() Line 230	C++
> vcllo.dll!SVMain() Line 249	C++
> sofficeapp.dll!soffice_main() Line 122	C++
> soffice.bin!sal_main() Line 51	C
> soffice.bin!main(int argc, char * * argv) Line 49	C
> soffice.bin!invoke_main() Line 79	C++
> soffice.bin!__scrt_common_main_seh() Line 288	C++
> soffice.bin!__scrt_common_main() Line 331	C++
> soffice.bin!mainCRTStartup(void * __formal) Line 17	C++
> kernel32.dll!BaseThreadInitThunk()	Unknown
> ntdll.dll!RtlUserThreadStart()	Unknown

The problem is null in pOutDev->mpGraphics, even after AcquireGraphics. pOutDev is vcl::WindowOutputDevice there. And its mxOwnerWindow->mpWindowImpl->mpFrame has mbGraphicsAcquired true, mpThreadGraphics null, and mpLocalGraphics non-empty.

It is curious that WinSalFrame::AcquireGraphics() returns null when already acquired! It may be what happens here.

Another problem - but IMO related - I saw with Vulcan. There, a loop in WindowOutputDevice::AcquireGraphics() was calling it, "while ( !mpGraphics )" - but again, it was always returning nullptr exactly because the frame's AcquireGraphics saw it's already initialized.
Comment 13 Mike Kaganski 2025-12-18 12:22:02 UTC 
The call stack for the hang with Vulkan - on DocumentEventNotifier thread:

> vcllo.dll!vcl::WindowOutputDevice::AcquireGraphics() Line 864	C++
> vcllo.dll!OutputDevice::ImplIsAntiparallel() Line 615	C++
> vcllo.dll!vcl::Window::GetPointerPosPixel() Line 548	C++
> vcllo.dll!vcl::Window::ImplTestMousePointerSet() Line 90	C++
> vcllo.dll!vcl::Window::LeaveWait() Line 630	C++
> vcllo.dll!SalInstanceWidget::set_busy_cursor(bool bBusy) Line 632	C++
> vcllo.dll!weld::WaitObject::~WaitObject() Line 628	C++
> dbulo.dll!dbaui::OLinkedDocumentsAccess::impl_open(const rtl::OUString & _rLinkName, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> & _xDefinition, dbaui::ElementOpenMode _eOpenMode, const comphelper::NamedValueCollection & _rAdditionalArgs) Line 147	C++
> dbulo.dll!dbaui::OLinkedDocumentsAccess::open(const rtl::OUString & _rLinkName, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> & _xDefinition, dbaui::ElementOpenMode _eOpenMode, const comphelper::NamedValueCollection & _rAdditionalArgs) Line 297	C++
> dbulo.dll!dbaui::OApplicationController::openElementWithArguments(const rtl::OUString & _sName, dbaui::ElementType _eType, dbaui::ElementOpenMode _eOpenMode, unsigned short _nInstigatorCommand, const comphelper::NamedValueCollection & _rAdditionalArguments) Line 1778	C++
> dbulo.dll!dbaui::OApplicationController::loadComponentWithArguments(long ObjectType, const rtl::OUString & ObjectName, unsigned char ForEditing, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & Arguments) Line 436	C++
> dbulo.dll!dbaui::OApplicationController::loadComponent(long ObjectType, const rtl::OUString & ObjectName, unsigned char ForEditing) Line 425	C++
> dbalo.dll!dbaccess::ODocumentDefinition::impl_openUI_nolck_throw(bool _bForEditing) Line 1802	C++
> dbalo.dll!dbaccess::ODocumentDefinition::open() Line 1839	C++
> mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214	C++
> mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 430	C++
> reflectionlo.dll!stoc_corefl::`anonymous namespace'::IdlInterfaceMethodImpl::invoke(const com::sun::star::uno::Any & rObj, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & rArgs) Line 593	C++
> sblo.dll!SbUnoObject::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 2226	C++
> svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 43	C++
> sblo.dll!SbxVariable::Broadcast(SfxHintId nHintId) Line 154	C++
> sblo.dll!SbxValue::SbxValue(const SbxValue & r) Line 68	C++
> sblo.dll!SbxVariable::SbxVariable(const SbxVariable & r) Line 48	C++
> sblo.dll!SbxMethod::SbxMethod(const SbxMethod & r) Line 841	C++
> sblo.dll!SbiRuntime::FindElement(SbxObject * pObj, unsigned long nOp1, unsigned long nOp2, ErrCode nNotFound, bool bLocal, bool bStatic) Line 3700	C++
> sblo.dll!SbiRuntime::StepELEM(unsigned long nOp1, unsigned long nOp2) Line 4195	C++
> sblo.dll!SbiRuntime::Step() Line 805	C++
> sblo.dll!`anonymous namespace'::RunInitGuard::run() Line 1021	C++
> sblo.dll!SbModule::Run(SbMethod * pMeth) Line 1181	C++
> sblo.dll!SbModule::Notify(SfxBroadcaster & rBC, const SfxHint & rHint) Line 776	C++
> svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 43	C++
> sblo.dll!SbMethod::Broadcast(SfxHintId nHintId) Line 2116	C++
> sblo.dll!SbxValue::Get(SbxValues & rRes) Line 289	C++
> sblo.dll!SbMethod::Call(SbxValue * pRet, SbxVariable * pCaller) Line 2072	C++
> basprovlo.dll!basprov::BasicScriptImpl::invoke(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aParams, com::sun::star::uno::Sequence<short> & aOutParamIndex, com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aOutParam) Line 262	C++
> protocolhandlerlo.dll!scripting_protocolhandler::ScriptProtocolHandler::dispatchWithNotification(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArgs, const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> & xListener) Line 213	C++
> protocolhandlerlo.dll!scripting_protocolhandler::ScriptProtocolHandler::dispatch(const com::sun::star::util::URL & aURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArgs) Line 286	C++
> dbalo.dll!dbaccess::`anonymous namespace'::lcl_dispatchScriptURL_throw(const unotools::WeakReference<dbaccess::ODatabaseDocument> & xWeakDocument, const com::sun::star::uno::Reference<com::sun::star::util::XURLTransformer> & xURLTransformer, const rtl::OUString & _rScriptURL, const com::sun::star::document::DocumentEvent & _rTrigger) Line 100	C++
> dbalo.dll!dbaccess::DocumentEventExecutor::documentEventOccured(const com::sun::star::document::DocumentEvent & Event) Line 169	C++
> dbalo.dll!comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::NotifySingleListener<com::sun::star::document::DocumentEvent>::operator()(const com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener> & listener) Line 252	C++
> dbalo.dll!comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::forEach<comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::NotifySingleListener<com::sun::star::document::DocumentEvent>>(const comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::NotifySingleListener<com::sun::star::document::DocumentEvent> & func) Line 278	C++
> dbalo.dll!comphelper::OInterfaceContainerHelper3<com::sun::star::document::XDocumentEventListener>::notifyEach<com::sun::star::document::DocumentEvent>(void(com::sun::star::document::XDocumentEventListener::*)(const com::sun::star::document::DocumentEvent &) NotificationMethod, const com::sun::star::document::DocumentEvent & Event) Line 293	C++
> dbalo.dll!dbaccess::DocumentEventNotifier_Impl::impl_notifyEvent_nothrow(const com::sun::star::document::DocumentEvent & _rEvent) Line 197	C++
> dbalo.dll!dbaccess::DocumentEventNotifier_Impl::processEvent(const comphelper::AnyEvent & _rEvent) Line 230	C++
> comphelper.dll!comphelper::AsyncEventNotifierBase::execute() Line 138	C++
> comphelper.dll!comphelper::AsyncEventNotifierAutoJoin::run() Line 246	C++
> comphelper.dll!threadFunc(void * param) Line 190	C++
> sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67	C++
> ucrtbased.dll!00007ff8bbfb2ec5()	Unknown
> kernel32.dll!BaseThreadInitThunk()	Unknown
> ntdll.dll!RtlUserThreadStart()	Unknown

mxOwnerWindow->mpWindowImpl->mpFrame has mbGraphicsAcquired true, mpThreadGraphics null, and mpLocalGraphics non-empty.
Comment 14 Commit Notification 2025-12-19 07:26:48 UTC 
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a086036723e0f358af2686ffc2a525627c4bb201

add asserts to WinSalFrame::ReleaseGraphics (tdf#169876 related)

It will be available in 26.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Noel Grandin 2025-12-19 11:23:30 UTC 
(In reply to Alex Thurgood from comment #8)
> Created attachment 204691 [details]
> Apple forced kill trace

Alex, is it possible for you get a better trace for the soffice process when it hangs? I cannot reproduce this on my mac, and Apple is unhelpfully removing the most important parts of the stack trace.

You should be able to do something like:

(*) open a terminal

(*) find the relevant process with
ps -ef | grep soffice

(*) start lldb with
lldb

(*) enter
  process attach --pid 123
in lldb

(*) enter
  bt all
in lldb

And then copy the output from the terminal and attach here.

Thanks.
Comment 16 Robert Großkopf 2025-12-22 10:39:40 UTC 
Seems the bug doesn't happen any more with daily build from 2025-Dec-19, downloaded 2025-12-22. Could it be the fix had been included in this build? (published 9:58, the fix had been published 7:26)
Comment 17 Alex Thurgood 2025-12-23 10:19:56 UTC 
No longer hanging for me with

Version: 25.8.4.2 (AARCH64)
Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df
CPU threads: 8; OS: macOS 26.2; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

The form opens after clicking on the Activate Macros button.
Comment 18 Saburo 2025-12-24 13:15:31 UTC 
Created attachment 204794 [details]
backtrace

still in
2025-12-24
Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 680(Build:0)
CPU threads: 12; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded

dumpfile
https://drive.google.com/file/d/1tQhzy3a4YveZf7mtUVWGDTjCpG3jhiDE/view?usp=sharing
Comment 19 Noel Grandin 2026-01-06 07:14:31 UTC 
On current master, I cannot reproduce this.

POssibly fixed with
    commit 90004b730eda4d06313f6e14603f1c1dad0f8f88
    Author: Noel Grandin <noelgrandin@gmail.com>
    Date:   Tue Dec 23 20:42:14 2025 +0200
    tdf#153554 fix crash when running python ODK tests
Comment 20 Saburo 2026-01-08 03:51:20 UTC 
It seems to be okay
2026-01-06
Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 680(Build:0)
CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: threaded

@Robert
Could you give it a try?
Comment 21 Robert Großkopf 2026-01-08 07:23:00 UTC 
(In reply to Saburo from comment #20)
> It seems to be okay
> 2026-01-06
> Version: 26.8.0.0.alpha0+ (X86_64)
> Build ID: 680(Build:0)
> CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan;
> VCL: win
> Locale: ja-JP (ja_JP); UI: ja-JP
> Calc: threaded
> 
> @Robert
> Could you give it a try?

I couldn't test it. No Windows system available here. Have only reported the bug because other users with Windows couldn't start an app I have created for bills.

If you couldn't reproduce it any more I will set this bug to FIXED. Could we please backport it also to LO 26.2?