Bug 141769 - Crash in: cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const &)
Summary: Crash in: cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::la...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: All Windows (All)
: high major
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.2.0 target:7.1.5
Keywords: bibisected, bisected, haveBacktrace, regression
: 141403 141624 142022 142024 142030 142691 142958 143289 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-04-20 08:46 UTC by skagon
Modified: 2021-08-20 23:13 UTC (History)
12 users (show)

See Also:
Crash report or crash signature: ["cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject const &)"]
Regression By:

Attachments
Spreadsheet opened prior to crash being experienced (280.05 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2021-05-02 03:04 UTC, Laurence 'GreenReaper' Parry 		Details
WinDbg stack trace with symbols against 7.1.3.2 with NVDA 2021.4 active (15.48 KB, text/plain)
2021-06-08 13:15 UTC, V Stuart Foote 		Details
Backtrace from disabling Function Bar on 7.1.3.2 (x86) - non-debug stack (4.55 KB, text/plain)
2021-06-08 23:46 UTC, Laurence 'GreenReaper' Parry 		Details
Backtrace of exception during ScAccessibleEditLineTextData::GetTextForwarder (1003 bytes, text/plain)
2021-06-08 23:55 UTC, Laurence 'GreenReaper' Parry 		Details
Backtrace of exception during ScAccessibleEditLineTextData::GetTextForwarder (8.07 KB, text/plain)
2021-06-08 23:57 UTC, Laurence 'GreenReaper' Parry 		Details
Show Obsolete (1) 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 skagon 2021-04-20 08:46:48 UTC 
This bug was filed from the crash reporting server and is br-6039fa92-6ecf-4aa6-b103-fca397897c75.
=========================================

LO crashes after opening a Calc instance and then closing the document (Ctrl-W) without doing anything else (not even clicking on any empty cell). Just open a Calc document from the Calc shortcut, wait for it to load, then Ctrl-W. Crash.
Comment 1 Xisco Faulí 2021-04-20 09:02:54 UTC Comment hidden (obsolete)
Comment 2 skagon 2021-04-20 10:20:32 UTC 
Xisco, there's no need for a sample document. An empty document or *any* ODS document will do. Calc crashes just by opening it and then closing the empty default document!
Comment 3 [REDACTED] 2021-04-20 11:27:28 UTC 
(In reply to skagon from comment #2)
> Xisco, there's no need for a sample document. An empty document or *any* ODS
> document will do. Calc crashes just by opening it and then closing the empty
> default document!

No repro

Version: 7.1.2.2 / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Please try to reset your user profile: https://wiki.documentfoundation.org/UserProfile
Comment 4 Laurence 'GreenReaper' Parry 2021-05-02 03:04:44 UTC 
Created attachment 171585 [details]
Spreadsheet opened prior to crash being experienced

It happened here, too, in the same situation - just open calc and close it again.
https://crashreport.libreoffice.org/stats/crash_details/5e8227d5-0310-4f72-8fd0-7ec7aa11f208

I had, however, previously opened the attached document and clicked through all the tabs, in case it matters. This was the crash from that instance:
https://crashreport.libreoffice.org/stats/crash_details/373be4ee-4131-4254-9770-f3cfa0d397c2

This is, deliberately (because it's smaller) the 32-bit version on 64-bit Windows.

I don't think it should really crash whatever the profile is. It appears to be happening at process cleanup, not loading the profile.
Comment 5 Timur 2021-05-14 14:12:34 UTC 
*** Bug 141403 has been marked as a duplicate of this bug. ***
Comment 6 Timur 2021-05-14 14:12:58 UTC 
*** Bug 142024 has been marked as a duplicate of this bug. ***
Comment 7 Timur 2021-05-14 14:14:52 UTC 
New by duplicates.
Comment 8 Timur 2021-05-14 14:18:31 UTC 
*** Bug 142030 has been marked as a duplicate of this bug. ***
Comment 9 Xisco Faulí 2021-05-14 14:24:52 UTC Comment hidden (obsolete)
Comment 10 Timur 2021-05-14 14:36:58 UTC 
From bug 141403:
Version: 7.1.1.2 (x64) / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL

Detailed status of reporter of bug 142024 in bug 142022:
Version: 7.1.2.2 (x64) / LibreOffice Community
  Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
  CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
  Locale: fr-FR (fr_FR); UI: fr-FR
  Calc: threaded
Comment 11 Xisco Faulí 2021-05-14 15:19:00 UTC Comment hidden (obsolete)
Comment 12 Beatriz A. 2021-05-14 15:30:45 UTC 
(In reply to Xisco Faulí from comment #11)
> For those who reproduce this issue.
> Do you reproduce it if you disable SKIA from Tools - Options - View ?

Yes
Comment 14 Laurence 'GreenReaper' Parry 2021-05-14 22:12:40 UTC 
Given the call stack, I tried to disable assistive technologies; however, this setting does not stick (the checkbox can be deselected but it returns on reopening the dialog or restarting the application).

I noticed there was a new version; it also reproduces on 7.1.3.2
https://crashreport.libreoffice.org/stats/crash_details/bea8c5ec-1481-4798-9e78-05ee5003b8f1
Comment 15 skagon 2021-05-14 23:47:37 UTC 
(In reply to Xisco Faulí from comment #9)
> Could you please paste the info from Help - about LibreOffice ?
> 
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' once the information has been provided

Here it is from me:

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: el-GR (en_GB); UI: en-GB
Calc: CL
Comment 16 Laurence 'GreenReaper' Parry 2021-05-14 23:51:06 UTC 
Version: 7.1.3.2 (x86) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-GB
Calc: threaded
Comment 17 Timur 2021-05-17 10:06:16 UTC 
*** Bug 141624 has been marked as a duplicate of this bug. ***
Comment 18 Buovjaga 2021-05-17 11:17:53 UTC 
I guess this should be NEW now with so many dupes
Comment 19 Xisco Faulí 2021-05-27 15:20:49 UTC 
*** Bug 142022 has been marked as a duplicate of this bug. ***
Comment 20 Xisco Faulí 2021-05-27 15:22:50 UTC 
Question for those reporting this issue, which is your java version in Tools - Options - Advanced, if any ?
Comment 21 Laurence 'GreenReaper' Parry 2021-05-27 18:44:14 UTC 
I have: Oracle Corporation version 1.8.0_291 under Program Files (x86).
Comment 22 skagon 2021-05-28 09:23:29 UTC 
(In reply to Xisco Faulí from comment #20)
> Question for those reporting this issue, which is your java version in Tools
> - Options - Advanced, if any ?

I have none.
Comment 23 Beatriz A. 2021-05-28 10:26:33 UTC 
(In reply to Xisco Faulí from comment #20)
> Question for those reporting this issue, which is your java version in Tools
> - Options - Advanced, if any ?

I don't have any.
Comment 24 V Stuart Foote 2021-05-30 14:34:06 UTC 
WinDbg stack traces available in attachment 171588 [details] (7.1.1.2) and attachment 171589 [details] (7.1.3.2) from dupe bug 142022 -- regression as same W10 Pro 64 20H2 (Version 10.0.19042 Build 19042) with 7.0.5.2 build has no issues. Not a driver or old hardware issue.
Comment 25 V Stuart Foote 2021-05-30 15:08:55 UTC 
I still can not reproduce on a range of Windows 10 systems with mix of CPUs and GPUs. 

However for those affected, the minidump crash reporter signature [1] shows this signature pretty solidly from 7.1.0.3 release build. Affecting a mix of AMD and Intel based CPUs, and AMD-Intel-nVidia GPUs.

=-ref-= [1] https://crashreport.libreoffice.org/stats/signature/cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject%20const%20&)
Comment 26 Michael Warner 2021-05-31 00:17:26 UTC 
Here I have encoded the ampersand in the crash report link so that it works properly:

https://crashreport.libreoffice.org/stats/signature/cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject%20const%20%26)
Comment 27 Michael Warner 2021-05-31 00:25:09 UTC 
Note that the Bugzilla linkifier isn’t including the closing paren in the link so you will have to add that manually in the location bar of your web browser.
Comment 28 Stephan Bergmann 2021-06-01 08:20:54 UTC 
(In reply to V Stuart Foote from comment #24)
> WinDbg stack traces available in attachment 171588 [details] (7.1.1.2) and
> attachment 171589 [details] (7.1.3.2) from dupe bug 142022

quoting the usable backtrace from attachment 171589 [details] for easier consumption:

> INVALID_POINTER_READ
>     Tid    [0x5d90]
>     Frame  [0x00]: cppuhelper3MSC!cppu::OInterfaceContainerHelper::disposeAndClear
> 
> 
> LAST_CONTROL_TRANSFER:  from 00007ff835aceca4 to 00007ff835aceb3a
> 
> STACK_TEXT:  
> 00000080`fd38e050 00007ff8`35aceca4 : 00000000`00000000 00000080`fd38e1d8 000001ef`23379818 000001ef`29de0920 : cppuhelper3MSC!cppu::OInterfaceContainerHelper::disposeAndClear+0x12a
> 00000080`fd38e0e0 00007ff8`35ac7dec : 000001ef`29de0920 000001ef`23379760 000001ef`23379818 00007ff8`638a0352 : cppuhelper3MSC!cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear+0xb4
> 00000080`fd38e130 00007ff8`08fbf177 : 000001ef`23379790 000001ef`23379760 00000000`00000000 000001ef`23379760 : cppuhelper3MSC!cppu::WeakAggComponentImplHelperBase::dispose+0xac
> 00000080`fd38e1d0 00007ff8`08ee8a0c : 000001ef`29bebf90 000001ef`2b751390 000001ef`2bdd9fe0 00007ff8`08ee896c : mergedlo!vcl::Window::dispose+0x657
> 00000080`fd38e340 00007ff8`08ed7d8b : 00000000`00000000 000001ef`2b751390 000001ef`29ccd180 00000000`00000001 : mergedlo!VclBuilder::disposeBuilder+0xbc
> 00000080`fd38e390 00007ff8`0930daae : 000001ef`29ccd180 000001ef`29ccd180 000001ef`2a3e1008 00000000`00008000 : mergedlo!VclBuilder::~VclBuilder+0x1b
> 00000080`fd38e3c0 00007ff8`09017037 : 000001ef`29e03b90 00000000`00000000 000001ef`2a3e1008 000001ef`29e03e08 : mergedlo!weld::Window::~Window+0x5ade
> 00000080`fd38e400 00007ff8`03093d17 : 000001ef`29e03b90 000001ef`29e03b90 00000080`fd38e4e9 000001ef`29de0150 : mergedlo!InterimItemWindow::dispose+0x67
> 00000080`fd38e440 00007ff8`06f751ff : 00000000`00000000 000001ef`2a3e0b00 00000000`ffffffff 00007ff8`06f7519c : sclo!ScFieldEditEngine::SetExecuteURL+0x2527
> 00000080`fd38e550 00007ff8`07e19cb7 : 000001ef`2a3e0b00 00000000`00008000 00000080`fd38e4f0 00007ff8`07e19c10 : mergedlo!basicide_handle_basic_error+0x103af
> 00000080`fd38e580 00007ff8`0308be6e : 00000000`00000001 00000080`fd38e729 00000000`0000ffff 000001ef`2bda30e0 : mergedlo!SfxChildWindow::~SfxChildWindow+0xc7
> 00000080`fd38e5b0 00007ff8`07e60bb1 : 000001ef`2bda30e0 000001ef`2bda30e0 00000000`0000ffff 00000000`00000001 : sclo!ScViewData::SetPasteMode+0xce4e
> 00000080`fd38e5e0 00007ff8`080c9dea : 000001ef`29fe6650 00000000`00000000 000001ef`29bebf90 00007ff8`080c9dc0 : mergedlo!com_sun_star_comp_desktop_QuickstartWrapper_get_implementation+0x5b01
> 00000080`fd38e690 00007ff8`080e5cd7 : 000001ef`2a8e6900 000001ef`2a8e6900 00000080`fd38e729 000001ef`1b40ee90 : mergedlo!SfxFrame::DoClose_Impl+0x3a
> 00000080`fd38e6c0 00007ff8`079a3ebb : 000001ef`29e02620 000001ef`2a8e68d8 000001ef`2a8e68d8 00000000`00000000 : mergedlo!SfxBaseController::dispose+0x4e7
> 00000080`fd38e790 00007ff8`0789d8fe : 000001ef`1cfddbf0 00000080`fd38e860 00000080`fd38e8c8 00000080`fd38e801 : mergedlo!framework_DispatchHelper_get_implementation+0xcf5b
> 00000080`fd38e840 00007ff8`0789d1a4 : 000001ef`1cfddbf0 000001ef`2a984838 000001ef`1baf7970 000001ef`227991f0 : mergedlo!com_sun_star_comp_framework_ModuleAcceleratorConfiguration_get_implementation+0xeede
> 00000080`fd38e8c0 00007ff8`0789c43c : 000001ef`22666dc8 000001ef`22666df8 000001ef`2a984301 00007ff8`06ee3e01 : mergedlo!com_sun_star_comp_framework_ModuleAcceleratorConfiguration_get_implementation+0xe784
> 00000080`fd38eaf0 00007ff8`079965fe : 00000000`00000000 000001ef`2a984360 00000080`fd38ec19 000001ef`2a984d48 : mergedlo!com_sun_star_comp_framework_ModuleAcceleratorConfiguration_get_implementation+0xda1c
> 00000080`fd38eb50 00007ff8`07996aff : 000001ef`2266ed01 00000080`fd38ee10 000001ef`2a984358 00000080`fd38ecb0 : mergedlo!com_sun_star_comp_framework_Desktop_get_implementation+0x12be
> 00000080`fd38ec70 00007ff8`079361d3 : 000001ef`2a984350 00000000`00000000 000001ef`2266e700 00007ff8`07996710 : mergedlo!com_sun_star_comp_framework_Desktop_get_implementation+0x17bf
> 00000080`fd38edb0 00007ff8`08fc93e0 : 00007ff8`638d50a0 ffffffff`ffff8001 000001ef`1cfddbd8 000001ef`2266f030 : mergedlo!com_sun_star_comp_framework_JobExecutor_get_implementation+0x5863
> 00000080`fd38ee60 00007ff8`0947ca3c : 000001ef`19c1c820 000001ef`1c1e58c0 00000000`00000000 00000000`00000246 : mergedlo!FloatingWindow::ImplSetMouseDown+0xc80
> 00000080`fd38f1e0 00007ff8`135b1a02 : 00000000`00000482 00000000`00000000 00000000`00000482 00000000`00000000 : mergedlo!SalFrame::CallCallback+0x1c
> 00000080`fd38f210 00007ff8`135b225d : 00000000`00000000 00000000`00000000 00000000`00000000 00000080`fd38f4a8 : vclplug_winlo!dtrans_CWinClipboard_get_implementation+0x4b072
> 00000080`fd38f370 00007ff8`6c3fe858 : 00000000`000d0a7e 00007ff8`00000482 00000000`00000000 000001ef`226677c0 : vclplug_winlo!dtrans_CWinClipboard_get_implementation+0x4b8cd
> 00000080`fd38f3e0 00007ff8`6c3fe299 : 00000000`00003dff 00007ff8`135b2210 00000000`000d0a7e 000001ef`00000482 : USER32!UserCallWinProcCheckWow+0x2f8
> 00000080`fd38f570 00007ff8`1353bd84 : 00007ff8`135b2210 00000000`00000001 00000000`00000000 00000000`00000001 : USER32!DispatchMessageWorker+0x249
> 00000080`fd38f5f0 00007ff8`1353b951 : 00007ff8`0b534101 00000000`00000001 00000000`00000001 000001ef`1b41a130 : vclplug_winlo+0x1bd84
> 00000080`fd38f680 00007ff8`0934e964 : 00000080`00000001 00007ff8`0b534110 00000000`0000ffff 00000000`00000000 : vclplug_winlo+0x1b951
> 00000080`fd38f6b0 00007ff8`08116135 : 000001ef`00000000 000001ef`1d460780 000001ef`1d45fd00 000001ef`1baf7970 : mergedlo!Application::Execute+0x164
> 00000080`fd38f710 00007ff8`0935dcd7 : 000001ef`1cc7da60 00007ff8`0b4ef270 00000000`00000000 00007ff8`0b534110 : mergedlo!SfxTabPage::set_visible+0x5795
> 00000080`fd38fa60 00007ff8`081378a3 : 000001ef`00000000 000001ef`177c0970 00007ff8`0b4ef270 00000000`00000000 : mergedlo!ImplSVMain+0x67
> 00000080`fd38fa90 00007ff7`1d6c105b : 000001ef`1afe6180 00000000`00000012 000001ef`177c0970 00007ff7`1d6c104c : mergedlo!soffice_main+0x133
> 00000080`fd38fb40 00007ff7`1d6c1308 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : soffice!main+0x1b
> 00000080`fd38fb70 00007ff8`6c347034 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : soffice!main+0x2c8
> 00000080`fd38fbb0 00007ff8`6e322651 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
> 00000080`fd38fbe0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21
Comment 29 Timur 2021-06-07 07:14:35 UTC 
*** Bug 142691 has been marked as a duplicate of this bug. ***
Comment 30 Timur 2021-06-07 07:34:07 UTC 
Common to reporters is Windows 10.0.19042.
Best would be to bibisect this crash, if someone can do it. 
Otherwise, maybe to try 10.0.19043.
Comment 31 Timur 2021-06-07 07:59:50 UTC 
Reporters, if you are using Dark mode or some customization, please write.
Comment 32 rlodato626 2021-06-07 13:05:37 UTC 
Comment from dup bug 142691:

I did the clean user profile run and recreated the crash. My log:

Reset to factory settings
Reset settings and user interface modifications
Reset entire user profile
Continue in Safe Mode

Edited and saved the spreadsheet in question. No issues until I closed that window. I then got a window titled "LibreOffice 7.1 Document Recovery" with "Due to an error, LibreOffice crashed. All the files you were working on will now be saved. The next time LibreOffice is launched, your files will be recovered automatically. The following files will be recovered:" with an empty list of files.

I started LibreOffice Calc again and got the "Crash Report". I did not select to "Restart LibreOffice to enter safe mode" and clicked on the "Do Not Send" button. A blank spreadsheet opened up. When I clicked the "X" to close it, it crashed again.

When I tried to restart, it entered a loop of starts and crashes. The splash window shows with the various status items. The last one to show before it crashes again is "Enabling: Wiki Publisher". Used Task Manager to kill LibreOffice.
Comment 33 V Stuart Foote 2021-06-07 14:33:10 UTC 
(In reply to Timur from comment #30)
> Common to reporters is Windows 10.0.19042.
> Best would be to bibisect this crash, if someone can do it. 
> Otherwise, maybe to try 10.0.19043.

No it is not. Reviewing the minidump crash reports [1] the details tabs show it is Windows 7, 8.1 and 10 including the latest 10.0.19043 build, while the meta tabs show it to affect both AMD & Intel CPU with a mix of AMD-Intel-nVidia GPUs--so unlikely anything to do with Windows desktop environment settings.

Still the volume of incedents is relatively low, not clear what mechanisim is causing this. It could be a LibreOffice locale (e.g. spellcheck/grammar check), or externally a Windows helper/framework, or even an AV instance.

Would be nice if someone affected can run the bibisect process [2] unfortunately I have been unaffected on six different Windows systems thus far and can't.

=-ref-=
[1] 
"https://crashreport.libreoffice.org/stats/signature/cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject%20const%20%26)"

[2] work against bibisect-win64-7.1 -- with instructions as in https://wiki.documentfoundation.org/QA/Bibisect/Windows
Comment 34 Laurence 'GreenReaper' Parry 2021-06-07 15:35:14 UTC 
I will try to have a look at it; unfortunately it is only downloading at 1.0-1.6MiB/sec for some reason, and so only 25% of the 256363 objects have been received thus far.

Hopefully it will reproduce for me as well under x86_64, as I have been using the 32-bit build as noted above and there is no bisect repository for that.
Comment 35 Laurence 'GreenReaper' Parry 2021-06-07 21:44:55 UTC 
Bibisect of crash succeeded on bibisect-win64-7.1

If I'm reading it right, this is the bad commit
https://git.libreoffice.org/core/+/e087e25f05e689091cbf1c4f91b6e93878ac17ec

Change: https://gerrit.libreoffice.org/c/core/+/104037

Changes were made to disposal-related code in
sc/source/ui/Accessibility/AccessibleText.cxx
and 
sc/source/ui/app/inputwin.cxx
among various other modifications.

This seems like it might correlate to crashes within VCLXAccessibleTextComponent::disposing() in https://crashreport.libreoffice.org/stats/crash_details/eabb9e50-2e65-41f2-9a39-5ad879b328be

Adding Cc: to Caolán McNamara <caolanm@redhat.com>

---

weld InputBar

this also restores that DnD of a selection from the inputbar is pasted as plain
text not rich text formatted with the happenstance formatting of the inputbar's
EditEngine

Change-Id: If4934f83c14357afec2e0a7e1d51c8a1aea1d292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104037
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>


tree: 8adb7ccbfa34e45e549a17bd9ee0a85067db1671

---

Bisect output:
 23127f0640852e8db00361827a2c1257381d11d6 is the first bad commit
commit 23127f0640852e8db00361827a2c1257381d11d6
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Oct 16 04:09:52 2020 -0700

    source sha:e087e25f05e689091cbf1c4f91b6e93878ac17ec

    source sha:e087e25f05e689091cbf1c4f91b6e93878ac17ec

 instdir/program/basctllo.dll                       | Bin 1814528 -> 1814528 bytes
 instdir/program/chartcontrollerlo.dll              | Bin 3416064 -> 3416064 bytes
 instdir/program/chartcorelo.dll                    | Bin 4113408 -> 4113408 bytes
 instdir/program/cuilo.dll                          | Bin 4847616 -> 4847616 bytes
 instdir/program/dbulo.dll                          | Bin 4796928 -> 4796928 bytes
 instdir/program/editenglo.dll                      | Bin 2950144 -> 2950144 bytes
 instdir/program/frmlo.dll                          | Bin 3028480 -> 3028480 bytes
 instdir/program/msfilterlo.dll                     | Bin 1287680 -> 1287680 bytes
 instdir/program/mswordlo.dll                       | Bin 3470336 -> 3470336 bytes
 instdir/program/ooxlo.dll                          | Bin 5701632 -> 5701632 bytes
 instdir/program/pcrlo.dll                          | Bin 1814016 -> 1814016 bytes
 instdir/program/rptlo.dll                          | Bin 1408000 -> 1408000 bytes
 instdir/program/rptuilo.dll                        | Bin 1672192 -> 1672192 bytes
 instdir/program/rptxmllo.dll                       | Bin 609792 -> 609792 bytes
 instdir/program/scfiltlo.dll                       | Bin 6928384 -> 6928384 bytes
 instdir/program/sclo.dll                           | Bin 21195776 -> 21190656 bytes
 instdir/program/scuilo.dll                         | Bin 1022976 -> 1022976 bytes
 instdir/program/sdfiltlo.dll                       | Bin 997888 -> 997888 bytes
 instdir/program/sdlo.dll                           | Bin 8723456 -> 8723456 bytes
 instdir/program/sduilo.dll                         | Bin 721408 -> 721408 bytes
 instdir/program/setup.ini                          |   2 +-
 instdir/program/smlo.dll                           | Bin 1624576 -> 1624576 bytes
 instdir/program/sofficeapp.dll                     | Bin 1530880 -> 1530880 bytes
 instdir/program/svgfilterlo.dll                    | Bin 1053184 -> 1053184 bytes
 instdir/program/svxcorelo.dll                      | Bin 10199040 -> 10199040 bytes
 instdir/program/svxlo.dll                          | Bin 4450816 -> 4450816 bytes
 instdir/program/swlo.dll                           | Bin 19734016 -> 19734016 bytes
 instdir/program/swuilo.dll                         | Bin 2975232 -> 2975232 bytes
 instdir/program/vbaobjlo.dll                       | Bin 2129408 -> 2129408 bytes
 instdir/program/vbaswobjlo.dll                     | Bin 1656832 -> 1656832 bytes
 instdir/program/version.ini                        |   2 +-
 instdir/program/writerfilterlo.dll                 | Bin 3244544 -> 3244544 bytes
 instdir/share/config/images_breeze.zip             | Bin 1886483 -> 1886483 bytes
 instdir/share/config/images_breeze_dark.zip        | Bin 1882148 -> 1882148 bytes
 instdir/share/config/images_breeze_dark_svg.zip    | Bin 1565502 -> 1565502 bytes
 instdir/share/config/images_breeze_svg.zip         | Bin 1563025 -> 1563025 bytes
 instdir/share/config/images_colibre.zip            | Bin 2771260 -> 2771260 bytes
 instdir/share/config/images_colibre_svg.zip        | Bin 2864630 -> 2864630 bytes
 instdir/share/config/images_elementary.zip         | Bin 4065290 -> 4065290 bytes
 instdir/share/config/images_elementary_svg.zip     | Bin 5060922 -> 5060922 bytes
 instdir/share/config/images_karasa_jaga.zip        | Bin 4882540 -> 4882540 bytes
 instdir/share/config/images_karasa_jaga_svg.zip    | Bin 19311495 -> 19311495 bytes
 instdir/share/config/images_sifr.zip               | Bin 2102952 -> 2102952 bytes
 instdir/share/config/images_sifr_dark.zip          | Bin 2104828 -> 2104828 bytes
 instdir/share/config/images_sifr_dark_svg.zip      | Bin 1754690 -> 1754690 bytes
 instdir/share/config/images_sifr_svg.zip           | Bin 1750825 -> 1750825 bytes
 instdir/share/config/images_sukapura.zip           | Bin 3041377 -> 3041377 bytes
 instdir/share/config/images_sukapura_svg.zip       | Bin 4346564 -> 4346564 bytes
 .../soffice.cfg/modules/scalc/ui/inputbar.ui       | 122 +++++++++++++++++++++
 49 files changed, 124 insertions(+), 2 deletions(-)
 create mode 100755 instdir/share/config/soffice.cfg/modules/scalc/ui/inputbar.ui

# bad: [10e2a57b0a703ab22c1eac2e9c495ab444c073c4] source sha:296c1b3b7e2fca6d54e3e61684d70d12f7989624
# good: [5dda870d87685eced00ca4ba6d5ceb48aff3c19e] source sha:574c57090642347980d2395e1e183cc7b5c171ad
git bisect start 'master' 'oldest'
# good: [17a6536d28165faf2aa32e32ca78323b414ccd03] source sha:e7b0e0b2b0df7197ee04c5c7232145d7a044bae0
git bisect good 17a6536d28165faf2aa32e32ca78323b414ccd03
# bad: [9be980890a6fa507b4c77176336367896060f35d] source sha:d6ed9cfe37a4a88e8f4911c004c0aea0b2568211
git bisect bad 9be980890a6fa507b4c77176336367896060f35d
# good: [ffc1246377962da8a9f6bb1d84121f1caafdebd2] source sha:10bda37a3c6470a46dadd859daa60a67ab53c29f
git bisect good ffc1246377962da8a9f6bb1d84121f1caafdebd2
# good: [e118dd4a98e6c6601b5586f9a7e4049b0b9b9f9a] source sha:64ca94ad591afc3134b600e05104b5d78ab60218
git bisect good e118dd4a98e6c6601b5586f9a7e4049b0b9b9f9a
# bad: [15e26685c2c56dbe34068a27cfeaf03406e1e355] source sha:606c65c90cb3e8abdd74540195b7cb01ba88adc8
git bisect bad 15e26685c2c56dbe34068a27cfeaf03406e1e355
# bad: [3a8d04fee0a8d9dcb2b44924349689d429b79874] source sha:55281fe6d3cda23d37b0b0c368786c9fc4c5abe9
git bisect bad 3a8d04fee0a8d9dcb2b44924349689d429b79874
# bad: [44d5143c6345a4dd1e0b21a29785ad0207cf7707] source sha:dd4670b976b00d643f335516fe5fd0c880d58025
git bisect bad 44d5143c6345a4dd1e0b21a29785ad0207cf7707
# bad: [85d08bbb8fea8e5e7a22e6e82197d19279ace77f] source sha:2df0e599090bc915362e1efb8eb27a37eccdc1f3
git bisect bad 85d08bbb8fea8e5e7a22e6e82197d19279ace77f
# good: [71415107b721fd706fa558a96e5c89cb7ba8f6c2] source sha:b12b1663d135f94eb56f3c1f852ef008e87c4e5f
git bisect good 71415107b721fd706fa558a96e5c89cb7ba8f6c2
# good: [c8f3fb6412fc500d679f707b0058bef32db00728] source sha:e1a47ddab37e70c400de254251be38e844117cc1
git bisect good c8f3fb6412fc500d679f707b0058bef32db00728
# bad: [77dc7c76543062ba871c7e0a4a8da5d98e4833ed] source sha:2e412c5354134fe3cd66ea0266011c5b87dc9eb3
git bisect bad 77dc7c76543062ba871c7e0a4a8da5d98e4833ed
# bad: [23127f0640852e8db00361827a2c1257381d11d6] source sha:e087e25f05e689091cbf1c4f91b6e93878ac17ec
git bisect bad 23127f0640852e8db00361827a2c1257381d11d6
# good: [70315057f8d86b3faed128933da35528ca3132df] source sha:d6b7cc3f7c07b98c90194e8b33cf44b94804b525
git bisect good 70315057f8d86b3faed128933da35528ca3132df
# first bad commit: [23127f0640852e8db00361827a2c1257381d11d6] source sha:e087e25f05e689091cbf1c4f91b6e93878ac17ec
Comment 36 Nico 2021-06-08 00:23:32 UTC 
As for the locale, am FR-FR, Windows 10 Pro 19042 (FR)
GPU Intel ; CPU : Intel
Up to LO 7.0.5, am ok, no issue. Any higher, even nightly builds, fail.
Comment 37 Laurence 'GreenReaper' Parry 2021-06-08 03:46:27 UTC 
As might be hinted at from the commit, it's not necessary to close the window to trigger the crash; just disable the Formula Bar via: View/Formula Bar.

The setting appears to be changed first, so subsequently restarting Calc and then closing the window will succeed without a crash, because there is no InputBox to dispose. This may be why it has not been universally reproducible.

It appears non-determinsitic as to whether disabling the Formula Bar causes a crash if you click the expand-down button and/or type content into the InputBox first. I have been able to close the Formula Bar and app, but not repeatably.

---

A bunch of code changed in that commit, so it's hard to pick out what caused it, but presumably those who know it might have a better idea.

I notice in ScAccessibleEditLineTextData (AccessibleText.cxx) existing isDisposed asserts were removed. How certain is it that mpTxtWnd isn't disposed? (These were commented out as "TODO" at one point?)

Class ScTextWnd has a WeakReference xAcc, but in ScTextWnd::CreateAccessible it is set to a Reference instead. The same pattern is used for ScEditWindow::CreateAccessible, but it looks to have been a bigger change for ScTextWnd, which has also modified disposal, eliminating steps and dispose() itself (called by ~ScAcessibleEditObject?) in favour of a destructor.
Comment 38 Caolán McNamara 2021-06-08 09:02:35 UTC 
the bisect is totally plausible but I can't get this to reproduce yet even on windows with its system accessibility screen reader enabled
Comment 39 Xisco Faulí 2021-06-08 09:32:35 UTC 
I couldn't find a way to reproduce it either. Tried with 2 different win machines
Comment 41 Caolán McNamara 2021-06-08 11:13:01 UTC 
If, under windows, I install nvda (https://www.nvaccess.org/) I get a reproducible crash that is very like this one so I might have a way in.
Comment 42 V Stuart Foote 2021-06-08 13:15:44 UTC 
Created attachment 172704 [details]
WinDbg stack trace with symbols against 7.1.3.2 with NVDA 2021.4 active

So, was able to reproduce with NVDA (2021.4) screen reader enabled. The AT facet had not come up in context or STR, but saw Caolán's note. With NVDA enabled, it does crash/recover current master and 7.1.3.2 builds on Windows 10 (20H2 build 19042.985)

Attaching a WinDbg stacktrace w/symbols against 7.1.3.2, if it helps.

That same crash on restart generated: https://crashreport.libreoffice.org/stats/crash_details/2f6d75b5-dbdf-42e1-b677-f7a366be01f1
Comment 43 Laurence 'GreenReaper' Parry 2021-06-08 23:46:10 UTC 
Created attachment 172716 [details]
Backtrace from disabling Function Bar on 7.1.3.2 (x86) - non-debug stack

TL;DR:  I end up in the same place with an invalid acquire(). Backtrace attached up to the exit. Not sure anything after this helps; apologies for the spam if not.

--

The bibisected build has no symbols, the released build does, so I opened that in Visual Studio. I was quickly reminded why I don't do that for complex projects. :-) 

From the looks of it, it ran into a notifications issue while disposing of the combo box down spinner button - but this may be a symptom of corruption before that.

It starts to dispose() ScInputWindow and when VS is set to run with a debug memory stack an access violation exception occurs via this call chain:
mxTextWindow.disposeAndClear()
m_xBuilder.reset()
VclBuilder::~VclBuilder()
VclBuilder::disposeBuilder()
 aI->m_pWindow.disposeAndClear() within rev. iteration of m_aChildren.rbegin()
Window::dispose()
 xC->dispose();
WeakAggComponentImplHelperBase::dispose()
 rBHelper.aLC.disposeAndClear( aEvt );
OMultiTypeInterfaceContainerHelper::disposeAndClear
 ppListenerContainers[i]->disposeAndClear( rEvt );
OInterfaceContainerHelper::disposeAndClear
 Reference<XEventListener > xLst( aIt.next(), UNO_QUERY );

at this point aIt.aData.pAsVector has supposedly three elements:
* OAccessibleWrapper [0] = {0x0c000850 {m_xParentAccessible={0x0c000704 ... and a chain above this}}  
* OAccessibleContentWrapper for a VCLAccessibleComponent (window) with {m_nNotifierClient=0x000003d4 }
* Junk with a broken vptr?

Exception thrown at 0x6E6D6B89 (cppuhelper3MSC.dll) in soffice.bin: 0xC0000005: Access violation reading location 0x00650066 (trying to call something on the junk vptr). This exception is caught so as to "be robust".

--

When *not* using a debug stack it proceeds past mxTextWindow.disposeAndClear() to dispose InterimItemWindow via aWndPos.disposeAndClear - going into VclReferenceBase::disposeOnce after clReferenceBase::release, resulting in m_xBuilder.reset() in InterimItemWindow::dispose(). (It never gets to  m_xVclContentArea.disposeAndClear().)

VclBuilder::disposeBuilder reverse iterates over m_aChildren. At the time of the crash it seems like there is (in order) a "PosBox" which has not been disposed, a "pos_window" that has an empty m_pWindow, and an empty element. It is currently within aI->m_pWindow.disposeAndClear(), at the point of calling VclReferenceBase::disposeOnce().

This in turn calls ComboBox::dispose() which is at the point of m_pImpl->m_pBtn.disposeAndClear() (having eliminated its subEdit, ListBox and floating window). In disassembly it is again calling VclReferenceBase::disposeOnce().

The combo box button has disposed of any status listener and calls Control::dispose(). This leads to pWrapper->WindowDestroyed( this ) from UnoWrapperBase::GetUnoWrapper in vcl::Window::dispose(), and that tries to call xWindowPeerComp->dispose(). This gets into VCL classes, and by the crash VCLXButton has finished off all its own disposal and is calling the base class VCLXGraphicControl::dispose() (VCLXWindow::dispose()). 

It's at this point we get mentions of accessibility:

// #i14103# dispose the accessible context after the window has been destroyed,
// otherwise the old value in the child event fired in VCLXAccessibleComponent::ProcessWindowEvent()
// for VclEventId::WindowChildDestroyed contains a reference to an already disposed accessible object
try
{
    css::uno::Reference< css::lang::XComponent > xComponent( mpImpl->mxAccessibleContext, css::uno::UNO_QUERY );
    if ( xComponent.is() )
>     xComponent->dispose();
}
catch ( const css::uno::Exception& )
{
    OSL_FAIL( "VCLXWindow::dispose: could not dispose the accessible context!" );
}
[by the crash, mpImpl->mxAccessibleContex is empty, xComponent.is() is true.]

It seems to anticipate some disposal failures, but maybe not the exception which ends up terminating the application. 

xComponent is a VCLXAccessibleButton. It enters WeakAggComponentImplHelperBase::dispose and calls rBHelper.aLC.disposeAndClear( aEvt ), then enters disposing(). This calls VCLXAccessibleComponent::disposing() - it'd later clear m_sText, which is empty.

This does DisconnectEvents() and then enters OAccessibleExtendedComponentHelper::disposing, which gets the SolarMutex guard and goes into AccessibleEventNotifier::revokeClientNotifyDisposing( m_pImpl->getClientId( ), *this ); ['this' being the VCLXAccessibleButton].

It's quite complex - comments reference prior re-entrancy problems - but proceeds to call pListeners->disposeAndClear( aDisposalEvent ). Here it becomes unstuck:

void OInterfaceContainerHelper2::disposeAndClear( const EventObject & rEvt )
{
    ClearableMutexGuard aGuard( rMutex );
>     OInterfaceIteratorHelper2 aIt( *this );

and this calls
OInterfaceIteratorHelper2::OInterfaceIteratorHelper2( OInterfaceContainerHelper2 & rCont_ )
    : rCont( rCont_ ),
      bIsList( rCont_.bIsList )
{
...
    else if( aData.pAsInterface )
    {
>        aData.pAsInterface->acquire();

Which appears for some reason to be a pure virtual call.
Comment 44 Laurence 'GreenReaper' Parry 2021-06-08 23:55:32 UTC Comment hidden (obsolete)
Comment 45 Laurence 'GreenReaper' Parry 2021-06-08 23:57:17 UTC 
Created attachment 172718 [details]
Backtrace of exception during ScAccessibleEditLineTextData::GetTextForwarder

(Switching comment and attachment...)

While debugging I encountered what seems to be accessibiliy-related exceptions in ScAccessibleEditLineTextData::GetTextForwarder; backtrace attached:

Exception thrown at 0x75D1A6F2 in soffice.bin: Microsoft C++ exception: com::sun::star::uno::RuntimeException at memory location 0x01B8F240.

This occurred a couple of times before I got to the loaded application with sheet. It goes through SfxWorkWindow::UpdateObjectBars_Impl and SfxWorkWindow::UpdateObjectBars_Impl into accessiblity-related code (see trace).

mpTxtWnd and mpForwarder are both null, and so pTextForwarder is null in AccessibleTextHelper_Impl::GetTextForwarder
So it throws uno::RuntimeException("Unable to fetch text forwarder, model might be dead", mxFrontEnd); [mxFrontEnd is also null]

Not sure if it is usual for this to occur or if it has relevance to the crash, but I figured if something failed in creating the accessibility events, it might also cause problems when accessibility-related stuff is being torn down.
Comment 46 Caolán McNamara 2021-06-09 10:33:35 UTC 
it would be a lot easier to debug this if visual studio didn't itself crash while nvda is running during stepping through the problem.
Comment 47 Timur 2021-06-09 12:45:37 UTC 
Well, we have a status Moved, like one can report to MS and turn on some music until it's fixed :)
Comment 48 Caolán McNamara 2021-06-09 13:36:11 UTC 
mpTextWnd being null is the problem I believe, we're waiting until the on-demand editview is created to set it but we need it before that

https://gerrit.libreoffice.org/c/core/+/116917

makes things work for me with what I see crashing for me under nvda
Comment 49 Commit Notification 2021-06-09 14:34:44 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

tdf#141769 ScTextWnd has to be available before the editview is created

It will be available in 7.2.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 50 Caolán McNamara 2021-06-09 14:50:15 UTC 
backport to 7-1 in gerrit. Testing welcome as there's always the chance I fixed something slightly different to what was initially reported given the initial trickiness of reproducing.
Comment 51 Laurence 'GreenReaper' Parry 2021-06-09 15:23:05 UTC 
Thanks for tracking it down! I know it's annoying when it's hard to reproduce.

Will give it a go when a build comes out (looks like they did a daily just before) or perhaps if it becomes available in the 7.1 bibisect tree prior to then.
Comment 52 V Stuart Foote 2021-06-09 16:10:46 UTC 
(In reply to Caolán McNamara from comment #50)
> ... always the chance I
> fixed something slightly different to what was initially reported given the
> initial trickiness of reproducing.

Caolán, * 

As in trace of comment 24 and comment 28?  Those do not seem to have an AT enabled...
Comment 53 Caolán McNamara 2021-06-09 16:33:11 UTC 
(In reply to V Stuart Foote from comment #52)
> As in trace of comment 24 and comment 28?  Those do not seem to have an AT
> enabled...
because there is no accessibility mentioned in the backtraces at the time of crash ?

My thinking is that there were earlier accessibility related calls which resulted in exceptions like that captured in comment #45 which leads to uncleaned up zombie objects attached to the inputbar TextWnd which then crashes when it's torn down. Well, maybe. I think I've fixed something worth fixing and we'll presumably see if it's sufficient.
Comment 54 V Stuart Foote 2021-06-09 16:44:57 UTC 
(In reply to Caolán McNamara from comment #53)
> (In reply to V Stuart Foote from comment #52)
> > As in trace of comment 24 and comment 28?  Those do not seem to have an AT
> > enabled...
> because there is no accessibility mentioned in the backtraces at the time of
> crash ?
> 

Yes

> My thinking is that there were earlier accessibility related calls which
> resulted in exceptions like that captured in comment #45 which leads to
> uncleaned up zombie objects attached to the inputbar TextWnd which then
> crashes when it's torn down. Well, maybe. 

I defer to your instinct on that :-)

> I think I've fixed something worth
> fixing and we'll presumably see if it's sufficient.

Absolutely--and thanks!  QA may have to poke folks on some of the dupes to be sure it really is quashed for all cases.
Comment 55 Xisco Faulí 2021-06-10 09:26:08 UTC 
For those who can reproduce the crash, Could you please try with the latest daily build from today < https://dev-builds.libreoffice.org/daily/master/current.html > ? it already contains Caolan's fix
Comment 56 Laurence 'GreenReaper' Parry 2021-06-10 15:16:16 UTC 
It works without crashing; which I'm guessing is a fix because it didn't before.

I get a bunch of exceptions and warnings and is very slow (presumably because it's non-optimized too; and the 64-bit version, which I don't regularly use). Many of these may be expected, but I don't know which, so here's what I saw:

When enabling the Formula Bar after it started disabled I got:
warn:legacy.osl:4288:3320:sc/source/ui/Accessibility/AccessibleEditObject.cxx:303: Should never be called, because is set in the constructor.
warn:legacy.osl:4288:3320:sc/source/ui/Accessibility/AccessibleContextBase.cxx:312: We should give always a name.

It was also very laggy when I first clicked inside the formula bar input box, or clicked out of it, with messages like:

Exception thrown at 0x00007FFC49B34B89 in soffice.bin: Microsoft C++ exception: com::sun::star::uno::RuntimeException at memory location 0x000000152498DCE8.
warn:sfx.control:4288:3320:sfx2/source/control/dispatch.cxx:1206: Childwindow slot missing: 25917
The thread 0x1fc0 has exited with code 0 (0x0).

...but I don't know if that is normal for the debug version.

When disabling the Formula Bar I got 38 instances of:

warn:legacy.osl:4288:3320:comphelper/source/misc/accessiblewrapper.cxx:458: OAccessibleContextWrapperHelper::disposing(): inner context is no broadcaster!

When selecting SUM from the Formula Bar Select Function dropdown I get:

Exception thrown at 0x00007FFC49B34B89 in soffice.bin: Microsoft C++ exception: com::sun::star::uno::RuntimeException at memory location 0x000000152498DD50.
Exception thrown at 0x00007FFC49B34B89 in soffice.bin: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
warn:svx:4288:3320:svx/source/accessibility/AccessibleTextHelper.cxx:1360: DBG_UNHANDLED_EXCEPTION in Notify exception: com.sun.star.uno.RuntimeException message: Text forwarder is invalid, model might be dead

When closing the document I again get a lot of:
OAccessibleContextWrapperHelper::disposing(): inner context is no broadcaster!
as well as eight instances of:
warn:legacy.osl:4288:3320:sc/source/ui/view/tabvwshh.cxx:232: no accessibility broadcaster?

Reopening a new Calc document renews:

warn:legacy.osl:4288:3320:sc/source/ui/Accessibility/AccessibleEditObject.cxx:303: Should never be called, because is set in the constructor.
warn:legacy.osl:4288:3320:sc/source/ui/Accessibility/AccessibleContextBase.cxx:312: We should give always a name.

warn:sfx.control:4288:3320:sfx2/source/control/dispatch.cxx:1206: Childwindow slot missing: 25917
warn:legacy.tools:4288:3320:sfx2/source/control/bindings.cxx:1764: No cache for OfficeDispatch!

When opening the Manage Names dialog I got:

Exception thrown at 0x00007FFC49B34B89 in soffice.bin: Microsoft C++ exception: com::sun::star::lang::IllegalArgumentException at memory location 0x000000152498D178.
warn:accessibility:4288:3320:accessibility/source/extended/AccessibleBrowseBoxBase.cxx:410: rectangle doesn't exist
warn:accessibility:4288:3320:accessibility/source/extended/AccessibleBrowseBoxBase.cxx:397: rectangle doesn't exist
warn:accessibility:4288:3320:accessibility/source/extended/AccessibleBrowseBoxBase.cxx:410: rectangle doesn't exist
[last three repeated two times]

and on closing it:

Exception thrown at 0x00007FFC49B34B89 in soffice.bin: Microsoft C++ exception: com::sun::star::uno::RuntimeException at memory location 0x000000152498DE40.
Exception thrown at 0x00007FFC49B34B89 in soffice.bin: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
warn:svx:4288:3320:svx/source/accessibility/AccessibleTextHelper.cxx:1360: DBG_UNHANDLED_EXCEPTION in Notify exception: com.sun.star.uno.RuntimeException message: Text forwarder is invalid, model might be dead

When selecting some text in the Function Bar I get:

Exception thrown at 0x00007FFC49B34B89 in soffice.bin: Microsoft C++ exception: `private: rtl::Reference<LogicalFontInstance> __cdecl ImplFontCache::GetFontInstance(PhysicalFontCollection const * __ptr64,FontSelectPattern & __ptr64) __ptr64'::`44'::limit_exception at memory location 0x000000152498D260.

After closing and opening a new Calc document with the Formula Bar set to be enabled on startup, it did not crash either, and could be disabled, with five instances of:

warn:legacy.osl:9348:10140:comphelper/source/misc/accessiblewrapper.cxx:458: OAccessibleContextWrapperHelper::disposing(): inner context is no broadcaster!
Comment 57 V Stuart Foote 2021-06-10 16:30:09 UTC 
(In reply to Laurence 'GreenReaper' Parry from comment #56)
> It works without crashing; which I'm guessing is a fix because it didn't
> before.
> 

@Laurence, are you able to run Windows without an assistive technology active? LibreOffice detects that state and responds enabling AT accordingly. Would be interesting as to the trace you get with AT not active. Both for Caolan's fixed build, and for a 7.1 release build or master without it.
Comment 58 Commit Notification 2021-06-10 19:14:54 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/4b6af3412f72be85706fc5355a36bd8364726c13

tdf#141769 ScTextWnd has to be available before the editview is created

It will be available in 7.1.5.

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 59 Laurence 'GreenReaper' Parry 2021-06-10 19:49:59 UTC 
That is perhaps the most confusing part of all this, as I was not aware I was using any accessibility technology. As such I'm not quite sure how to turn it off! The checkbox in Accessibility is autoselected, and deselecting it does not "stick" (which I think is itself a bug, in that if it can't be unset it should not be enabled).

I had a look at what might enable it but HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Accessibility has a blank Configuration REG_SZ setting. I was a little confused when I couldn't find a LibreOffice registry folder, but found I had an Accessibility EnableATToolSupport fuse entry in registrymodifications.xcu set to true. I tried changing this to false but it was set back to true just by opening and closing the LO launcher again.

Looking at the source, you use HasAtHook() in salplug.cxx which is looking at SystemParametersInfoW(SPI_GETSCREENREADER, ...). And running PowerShell also indicates that I "might be using a screen reader". I also enabled SAL_LOG for vcl info messages and got "got IAccessible2 bridge" from svdata.cxx:336. So I guess there may be an app installed which is triggering this?

Not sure what it might be, or how to identify that - I do have graphics tablet software installed as well as a DisplayLink USB to VGA screen. Oracle Java 8 appears to have an Accessibility tool registered as well, but I am guessing that is normal for the JRE.

One weird thing is that trying to access the Narrator tab freezes Windows Settings. The same happens if I try to access the Settings/Updates & Security/For developers. So there is definitely Something Up (TM)
Comment 60 Nico 2021-06-10 20:52:07 UTC 
As from Comment #55, it fixes the crash I was reporting #142022 and others... and linked to this thread...
Many thanks for deploying ressources and focusing... I was over some time ago... side of DBLG was to tweaky for me ;o) 
Just discovered bibisected !

Am not able to focus AT form Windows... in order to disable and test previous version...
Comment 61 Laurence 'GreenReaper' Parry 2021-06-10 21:51:01 UTC 
@Nico: It's interesting that you mention Lenovo in bug 142022, as this device is a Lenovo x120e. I wouldn't entirely put it past them to have some kind of screen reader integration (they've also had buggy plugins that leak handles before).

Unfortunately this device is my main system right now (waiting on AMD's Van Gogh with RDNA2+AV1 decode to replace it), and the main screen is broken, so I don't feel too confident in removing the default device packages to test out whether it removes the screen reader flag.

@V Stuart Foote: If you want me to test that, I think I'll need a way to force the accessible mode off in LibreOffice. I could try making a utility to disable it by setting the relevant system parameter to false, but I'm not sure that would work (I would've thought it's a global OR across all applications that can set it). Or maybe you know some way to identify the triggering application so as to remove it?
Comment 62 Nico 2021-06-10 22:00:55 UTC 
Formerly Thinkpad X380, touchscreen, pen
About up to date (from Lenovo vantage), slightly dated from Intel's support page. Windows update about to be synced
I can test previous vers and this one, but please ask what to look at ?
Comment 63 V Stuart Foote 2021-06-10 22:57:39 UTC 
(In reply to Laurence 'GreenReaper' Parry from comment #61)
>...
> @V Stuart Foote: If you want me to test that, I think I'll need a way to
> force the accessible mode off in LibreOffice. I could try making a utility
> to disable it by setting the relevant system parameter to false, but I'm not
> sure that would work (I would've thought it's a global OR across all
> applications that can set it). Or maybe you know some way to identify the
> triggering application so as to remove it?

I don't think we can. We use the SPI_GETSCREENREADER call [1] to set the HasATHook(). The Tools -> Options -> Accessibility 'Support assistive technology tools' will always toggle on when the system reports it in use. That was hard coded when we replaced the Java Access Bridge to UAA calls on Windows builds with native IAccessible2 mappings at the 4.3.0 release.

Would have to identify the Windows 10 app that is setting the screenreader enabled and disable it. Spent some time poking around StackOverflow but I could not find an effective way.

 https://opengrok.libreoffice.org/xref/core/vcl/source/app/salplug.cxx?r=fa8db25a#397
Comment 64 V Stuart Foote 2021-06-20 18:38:57 UTC 
*** Bug 142958 has been marked as a duplicate of this bug. ***
Comment 65 Timur 2021-07-15 12:11:40 UTC 
*** Bug 143289 has been marked as a duplicate of this bug. ***
Comment 66 Laurence 'GreenReaper' Parry 2021-08-20 23:13:44 UTC 
Verified fixed in 7.1.5.2 - thanks everyone for your work!