Bug 153131 - Copy causes Calc to Freeze on Windows 11 with Speech Recognition (comment 58)
Summary: Copy causes Calc to Freeze on Windows 11 with Speech Recognition (comment 58)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.4.4.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
: 156290 156500 (view as bug list)
Depends on:
Blocks: a11y-Windows Cut-Copy
  Show dependency treegraph
 
Reported: 2023-01-20 22:53 UTC by ericbresslermd
Modified: 2023-12-28 14:37 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Very Sleepy output of soffice.bin (stopped during hang after copy) (73.85 KB, application/zip)
2023-09-15 08:44 UTC, Barry L. Kramer
Details
Very Sleepy output of soffice.bin (stopped after copy, no hang) (6.93 KB, application/zip)
2023-09-15 08:50 UTC, Barry L. Kramer
Details
output of procdump (7.89 MB, application/octet-stream)
2023-09-17 01:54 UTC, Barry L. Kramer
Details
Very Sleepy output of Dev 24 soffice.bin (stopped during hang after copy) (38.76 KB, application/zip)
2023-09-17 04:00 UTC, Barry L. Kramer
Details
Very Sleepy output of Dev 24 soffice.bin (stopped after successful copy) (6.05 KB, application/zip)
2023-09-17 04:02 UTC, Barry L. Kramer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ericbresslermd 2023-01-20 22:53:20 UTC
On both OpenOffice and LibreOffice 7.4 current release, using Copy causes program to freeze. This started when I "upgraded" from Windows 10 to Windows 11. It freezes no matter whether I right-click/Copy or whether I choose it from the Edit Menu. Pasting from other programs still works, though.
Comment 1 m_a_riosv 2023-01-21 00:49:34 UTC
Please test in safe mode, Menu/Help/Restart in Safe Mode
Comment 2 ericbresslermd 2023-01-21 19:39:06 UTC
I tried restarting in safe mode. The problem is still present: using Copy from either the Edit menu or from right-click/Copy causes the program to freeze up. This is some kind of conflict with Windows 11 as the problem started when I made that OS upgrade. I don't have the problem on a version of Apache Open Office on my laptop running Windows 10 (a corporate machine, I don't have admin rights on it).
Comment 3 m_a_riosv 2023-01-21 23:48:27 UTC
Please test if modifying Skya status has some effect.
Menu/Tools/Options/View
Comment 4 ericbresslermd 2023-01-22 17:23:48 UTC
There was no change in the "copy" problem. I unchecked "Use Skia for all rendering" and restarted LO. No change. I checked "Use Skia..." and restarted, and no change.
Comment 6 ericbresslermd 2023-01-22 19:54:57 UTC
I did have Windows Clipboard History turned on. No other clipboard manager is being used. I turned it off and restarted the PC. The Copy problem is still present. Good idea, though!
Comment 7 m_a_riosv 2023-01-23 00:07:09 UTC
I can't find any other similar report, and I don't have win 11 test.
Let's see if someone else can test.

Meanwhile, you can try to see in the Task manager / Details, sorting CPU (inverse) if there is some program with a high usage when this happens.
Comment 8 ericbresslermd 2023-01-23 00:45:11 UTC
Thanks for looking at this. When I have Task Manager open and try to use Copy in LO Calc, when LO Calc freezes the LibreOffice CPU usage goes to 26%, and its memory usage progressively increases from 204 MB to over 1,300 MB within about 30 seconds. I closed the program as it started taking over the Memory!
Comment 9 ericbresslermd 2023-01-23 00:46:23 UTC
No other program increases CPU or memory usage when this problem occurs.
Comment 10 m_a_riosv 2023-01-23 00:55:15 UTC
Can you try to uninstall, and rename/delete the profile (https://wiki.documentfoundation.org/UserProfile), and reinstall again?
Comment 11 ericbresslermd 2023-01-23 01:04:56 UTC
The problem persisted when I entered safe mode previously. So according to the UserProfile Wiki, the profile is not problem, right?
Comment 12 ericbresslermd 2023-01-23 01:23:27 UTC
I tried the manual procedure, too, renaming the user file user-old and restarting the program to create a new user file. The copy problem in Calc persists. That's with it using .ods .xls and .xlsx format files, although once in a while the program doesn't crash the first time I try using Copy.
Comment 13 ericbresslermd 2023-01-23 01:34:59 UTC
I renamed the User-old, uninstalled LibreOffice 7.4.4.2 and installed 7.3.7.2. The Calc Copy problem persists in crashing the program. I've reverted to my old profile now.
Comment 14 Buovjaga 2023-01-27 16:53:59 UTC
On Windows 11

1. Created a new Calc spreadsheet
2. Copied cell A1

No freeze. Memory use did not increase at all.

Version: 7.4.5.0.0+ (x64) / LibreOffice Community
Build ID: 610880abd9f3be00451db51f05b7f4772c389b7a
CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_FI); UI: en-US
Calc: threaded
Comment 15 ericbresslermd 2023-01-27 17:22:43 UTC
(In reply to Buovjaga from comment #14)
> On Windows 11
> 
> 1. Created a new Calc spreadsheet
> 2. Copied cell A1
> 
> No freeze. Memory use did not increase at all.
> 
> Version: 7.4.5.0.0+ (x64) / LibreOffice Community
> Build ID: 610880abd9f3be00451db51f05b7f4772c389b7a
> CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL:
> win
> Locale: en-US (en_FI); UI: en-US
> Calc: threaded

I'm not a developer or a programmer. Why does the information you included say Windows 10.0 instead of Windows 11?
Comment 16 Buovjaga 2023-01-27 17:29:03 UTC
(In reply to ericbresslermd from comment #15)
> I'm not a developer or a programmer. Why does the information you included
> say Windows 10.0 instead of Windows 11?

Because Microsoft decided this is the way things are. You can see it in your Help - About window and by the way, you should always copy the information from there into your bug reports.
Comment 17 ericbresslermd 2023-01-27 17:37:15 UTC
Here is my PC's info. As yo ucan see, it says Windows 11 Pro.

Device name	DESKTOP-LADH9BG
Processor	Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz   2.90 GHz
Installed RAM	16.0 GB (15.7 GB usable)
Device ID	13BD424F-635E-46AF-B83B-8771CA06B7DB
Product ID	00330-52927-20105-AAOEM
System type	64-bit operating system, x64-based processor
Pen and touch	No pen or touch input is available for this display

Edition	Windows 11 Pro
Version	22H2
Installed on	‎11/‎15/‎2022
OS build	22621.1105
Experience	Windows Feature Experience Pack 1000.22638.1000.0
Comment 18 Buovjaga 2023-01-27 17:47:40 UTC
(In reply to ericbresslermd from comment #17)
> Here is my PC's info. As yo ucan see, it says Windows 11 Pro.
> 
> Device name	DESKTOP-LADH9BG
> Processor	Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz   2.90 GHz
> Installed RAM	16.0 GB (15.7 GB usable)
> Device ID	13BD424F-635E-46AF-B83B-8771CA06B7DB
> Product ID	00330-52927-20105-AAOEM
> System type	64-bit operating system, x64-based processor
> Pen and touch	No pen or touch input is available for this display
> 
> Edition	Windows 11 Pro
> Version	22H2
> Installed on	‎11/‎15/‎2022
> OS build	22621.1105
> Experience	Windows Feature Experience Pack 1000.22638.1000.0

No, that's not what I meant. Help - About *in LibreOffice*. Click the copy button and do not close the window before pasting.
Comment 19 ericbresslermd 2023-01-27 17:57:15 UTC
Version: 7.3.7.2 (x64) / LibreOffice Community
Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f
CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 20 Karthikeyan 2023-01-29 07:20:50 UTC
1.Steps followed to reproduce
i. Created a new Calc spreadsheet
ii. Copied cell A1
No freeze. Memory use did not increase at all.
2.Environment:
os windows 11,RAM 8GB,ROM 512,version 7.6.0.0 alpha0+(*86)/Libraoffice
3.Result:Bug not reproduced
4.Status:unconfirmend
Comment 21 ericbresslermd 2023-01-29 20:51:57 UTC
Thanks,  Karthikeyan.  When I follow the same procedure, my LibreOffice freezes every time. It doesn't matter whether there is anything in the A1 cell or not, or whether the new spreadsheet has been saved or not.
Comment 22 ericbresslermd 2023-02-15 15:31:42 UTC
The program also freezes when I try to use the Cut commands from both the Edit Menu and from right-click/Cut.
Comment 23 Denis 2023-05-24 16:33:13 UTC
In Windows 10, in current LO (7.4.7) and previous LO (7.4.6). When copying from a calc cell to the search box in another spreedsheet, Calc is completely frozen (I have to stop it with ctl-alt-del). Happened 3 times thus far during about 1 month. I open usually many spreedsheets but didn't keep a log of how many. Last time, 6 files. 

Running at the same time (I don't know how to get the crash report):
seamonkey, firefox and chrome, notepad++, old Forte Agent, command prompt.
Comment 24 Denis 2023-05-24 16:35:42 UTC
(In reply to Denis from comment #23)
> In Windows 10, in current LO (7.4.7) and previous LO (7.4.6). When copying
> from a calc cell to the search box in another spreedsheet, Calc is
> completely frozen (I have to stop it with ctl-alt-del). Happened 3 times
> thus far during about 1 month. I open usually many spreedsheets but didn't
> keep a log of how many. Last time, 6 files. 
> 
> Running at the same time (I don't know how to get the crash report):
> seamonkey, firefox and chrome, notepad++, old Forte Agent, command prompt.

Version: 7.4.7.2 (x64) / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: fr-CA (fr_CA); UI: fr-FR
Calc: threaded
Comment 25 m_a_riosv 2023-05-24 18:43:28 UTC
Now with win11 I can't repro.
Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL threaded

You don't have OpenCL enable, maybe because don't pass the LibreOffice test to enable it.

Try to update the driver of video card from the manufacturer.
Comment 26 Barry L. Kramer 2023-07-15 03:01:59 UTC
I think I might have the same problem but on a different configuration. See my bug report for Bug 156290

I found a possible work around that you could try. Try running calc from the command prompt using scalc.exe like I describe in 156290.
Comment 27 ericbresslermd 2023-07-15 20:07:18 UTC
Thanks, Barry. Unfortunately I can't run scalc.exe from my command prompt using the text you included in your bug report for https://bugs.documentfoundation.org/show_bug.cgi?id=156290
Comment 28 ysui2022 2023-07-20 04:58:19 UTC
I can't reproduce this with windows 11
Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 29 Aaron 2023-08-08 23:22:27 UTC
*** Bug 156500 has been marked as a duplicate of this bug. ***
Comment 30 Judith 2023-08-13 19:13:22 UTC
Thank you. My report 156500 was a duplicate of this. The solution outlined at https://bugs.documentfoundation.org/show_bug.cgi?id=156290 is working for me.  I used the simple prompt without defining UserInstallation.  My thanks to all who have contributed!
Comment 31 m_a_riosv 2023-08-14 00:23:09 UTC
Test repairing LibreOffice installation.
https://support.microsoft.com/en-us/windows/uninstall-or-remove-apps-and-programs-in-windows-4b55f974-2cc6-2d2b-d092-5905080eaf98
select repair with right-click, instead uninstall.
Comment 32 ericbresslermd 2023-08-14 14:42:00 UTC
I just tried to Repair the installation, but that didn't work to squash the bug.
Comment 33 Judith 2023-08-14 15:20:08 UTC
I had also tried the repair on July 31, and it didn't work.
Comment 34 m_a_riosv 2023-08-14 16:34:15 UTC
BTW, there are a lot of resources about "Windows 11 Freezes Randomly", searching in the web.
Comment 35 Buovjaga 2023-09-13 07:00:06 UTC
In bug 156290 comment 3 Eric said:
(In reply to ericbresslermd from comment #3)
> Using the command prompt with this command as suggested by Barry Kramer did
> prevent the hanging from using Copy and Cut on my system.
> 
> "C:\Program Files\LibreOffice\program\scalc.exe"
> 
> The -env:UserInstallation= etc. did not work; fatal error as user
> installation could not be completed.

Let's set this to new and close the newer one.
Comment 36 Buovjaga 2023-09-13 07:00:18 UTC
*** Bug 156290 has been marked as a duplicate of this bug. ***
Comment 37 Buovjaga 2023-09-13 07:41:25 UTC
I mentioned this in the dev chat and there was a suggestion to install Very Sleepy http://www.codersnotes.com/sleepy/ to grab some stacktraces of the soffice process. For this to work, you need to install the debug build Win-x86@39 from https://dev-builds.libreoffice.org/daily/master/current.html

The master build installs separately.
Comment 38 Buovjaga 2023-09-13 11:28:27 UTC
Another comment from the chat:
'shortcuts on Windows may include some "run in compat mode" options - I don't think our installer sets those, but they could e.g. be set by installer by default when detecting some manifest (or its absense); or it could be set by the super-smart system after a crash'

So you could right-click the shortcut on the desktop, select Properties and click the Compatibility tab. For me, none of the checkboxes are checked.
Comment 39 Buovjaga 2023-09-13 12:24:46 UTC
(In reply to Buovjaga from comment #37)
> I mentioned this in the dev chat and there was a suggestion to install Very
> Sleepy http://www.codersnotes.com/sleepy/ to grab some stacktraces of the
> soffice process. For this to work, you need to install the debug build
> Win-x86@39 from https://dev-builds.libreoffice.org/daily/master/current.html
> 
> The master build installs separately.

Another note came up: you don't have to install the debug build as all release builds can get symbols via the symbol server.

In Very Sleepy: Tools - Options - Symbol server location, add to the existing text:

;https://dev-downloads.libreoffice.org/symstore/symbols
Comment 40 Barry L. Kramer 2023-09-13 22:01:19 UTC
My system still has this problem. I am a computer engineer by trade and I will try to use these tools to get you the information you need. I am not familiar with them right now so I will need a while to review the documentation to learn exactly how to do this.

In the meantime I can confirm that there are no compatibility mode settings applied to the shortcut on my windows system. To reiterate, running calc from the shortcut will demonstrate the hang problem, but running scalc at the command line does not. So I will try to compare the two situations.
Comment 41 Mike Kaganski 2023-09-14 05:42:48 UTC
(In reply to Barry L. Kramer from Bug 156290 comment #0)
> Running Calc from the Windows shortcut:
> 
> ...
> 
> The following is my
> workaround for getting Calc to run without crashing: from a CMD prompt:
> 
> C:>"C:\Program Files\LibreOffice\program\scalc.exe"

And which shortcut is meant exactly? The direct one for Calc (also running scalc.exe)? Or the generic running soffice.exe?

Does a new shortcut created for the executable(s) manually show the same problem?
Comment 42 Barry L. Kramer 2023-09-14 23:12:35 UTC
(In reply to Mike Kaganski from comment #41)

> And which shortcut is meant exactly? The direct one for Calc (also running
> scalc.exe)? Or the generic running soffice.exe?


The one for Calc that was created by the installer in the apps menu.  It is located in:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\LibreOffice 7.5
and its target is:
"C:\Program Files\LibreOffice\program\scalc.exe"
with Start In set to "C:\Program Files\LibreOffice\"


For more info, please see my original report as Bug 156290 (now marked as a duplicate... I looked for other reports but did not find one until later.)
https://bugs.documentfoundation.org/show_bug.cgi?id=156290


> Does a new shortcut created for the executable(s) manually show the same
> problem?

Yes.  I also tried a different Start In location - still hangs on copy.
And I tried using the LibreOffice shortcut then selecting Create: Calc Spreadsheet - still hangs on copy.


blk
Comment 43 Mike Kaganski 2023-09-15 06:40:06 UTC
(In reply to Buovjaga from comment #37)

We also have a documentation on producing backtraces on Windows:

https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump

Having a minidump would definitely help.
Comment 44 Barry L. Kramer 2023-09-15 08:44:58 UTC
Created attachment 189602 [details]
Very Sleepy output of soffice.bin (stopped during hang after copy)

This is the output of Very Sleepy profile of the soffice.bin process. Started profiling after Calc is running on a blank (new document); stopped after hang that occurred after pressing ^C with default selection (on cell A1).
Calc was run from the windows Calc shortcut.

Windows version:
Edition	Windows 11 Home
Version	22H2
Installed on	‎2/‎22/‎2023
OS build	22621.2283
Experience	Windows Feature Experience Pack 1000.22662.1000.0

Java version 8 update 371

Calc version:
Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 45 Barry L. Kramer 2023-09-15 08:50:49 UTC
Created attachment 189603 [details]
Very Sleepy output of soffice.bin (stopped after copy, no hang)

This is the same soffice.bin profiling output, except in this case when Calc was invoked from the cmd prompt (scalc).  I did the same ^C to copy cell A1, then stopped the profiling, with no hang, since it hangs when run from the windows shortcut but not when invoked using scalc.exe.
Comment 46 Barry L. Kramer 2023-09-17 01:54:15 UTC
Created attachment 189644 [details]
output of procdump

(In reply to Mike Kaganski from comment #43)
> (In reply to Buovjaga from comment #37)
...
> Having a minidump would definitely help.


Everyone,
I was able to get the development tools running, and I do still see this problem on the debug build which is great.  I am using the following version of Dev 24:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b3fdd999f87312447d03915585812b3a5cd48141
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Attached is the output of procdump.exe soffice.bin -h
Comment 47 Barry L. Kramer 2023-09-17 04:00:22 UTC
Created attachment 189646 [details]
Very Sleepy output of Dev 24 soffice.bin (stopped during hang after copy)

This is the output of the debug version (Dev 24), stopped during hang after Copy cell A1 when Calc is run from the desktop shortcut.
Comment 48 Barry L. Kramer 2023-09-17 04:02:18 UTC
Created attachment 189647 [details]
Very Sleepy output of Dev 24 soffice.bin (stopped after successful copy)

This is the output of the debug version (Dev 24), stopped after Copy cell A1 worked when Calc is run from the exe (scalc) at the command line (in cmd).
Comment 49 Mike Kaganski 2023-09-17 08:02:48 UTC
Unfortunately, I don't see a way to use the Very Sleepy results: at least I don't know how to see the *specific* backtrace of every active thread at the moment when the file was generated. The profiling info (the main goal of the Very Sleepy tool) is uninteresting to me; only the traces are, but the traces available in the tool are not bound to the program states, but to function time statistics.

The wiki mentioned in comment 43 does not mention any "Very Sleepy"...
Comment 50 Barry L. Kramer 2023-09-17 09:25:35 UTC
(In reply to Mike Kaganski from comment #49)
> 
> The wiki mentioned in comment 43 does not mention any "Very Sleepy"...

True. Very Sleepy was mentioned in comment 37 and comment 39.

The minidump from the wiki mentioned in comment 43 is in the attachment of comment 46.

I think I followed the instructions in the wiki, and the .dmp file can be loaded into WinDbg (X64).  This is the first time I'm doing this, so if I made a mistake or if I can do it differently, please let me know. I'd even be willing to use other tools or WinDbg in other ways but I would need some direction as I'm completely unfamiliar with LO except as a user, although I have lots of development experience.
Comment 51 Mike Kaganski 2023-09-17 11:45:40 UTC
(In reply to Barry L. Kramer from comment #50)
> The minidump from the wiki mentioned in comment 43 is in the attachment of
> comment 46.

Ah! Yes, you are completely correct. I missed that somehow.
Do you use some accessibility software?
Comment 52 Mike Kaganski 2023-09-17 13:02:45 UTC
(In reply to Barry L. Kramer from comment #46)
> I am using the following version of Dev 24:
> 
> Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: b3fdd999f87312447d03915585812b3a5cd48141

Is that your own build? I haven't found it in our dailies (the one from Sep 14 there is 4942aa1533af25cf102da7516bd5e521c553aa07, i.e. several commits later, and its binaries aren't accepted to debug this minidump)
Comment 53 Mike Kaganski 2023-09-17 14:08:13 UTC
I believe that the best would be a minidump for some *release* version - because we have symbols for them on our symbol server. Any local or daily build would have a symbols missing problem...
Comment 54 Barry L. Kramer 2023-09-17 22:37:38 UTC
(In reply to Mike Kaganski from comment #52)
> 
> Is that your own build? I haven't found it in our dailies


No, I don't know how to build it yet. I used the link in one of the comments (https://dev-builds.libreoffice.org/daily/master/current.html) and chose "Win-x86_64@tb77-TDF  2023-09-15 05:28:33".  I'll try to find a debug version.  Do you have a link I should follow?  I would be happy to run it again....
Comment 55 Mike Kaganski 2023-09-18 04:34:08 UTC
(In reply to Barry L. Kramer from comment #54)
> Do you have a link I should follow?  I would be happy to run it again....

I would be clad if you create a minidump using any release version - the normal one, like 7.5.4.2 that you used in comment 44.
Comment 56 Buovjaga 2023-09-18 05:50:03 UTC
(In reply to Barry L. Kramer from comment #54)
> (In reply to Mike Kaganski from comment #52)
> > 
> > Is that your own build? I haven't found it in our dailies
> 
> 
> No, I don't know how to build it yet. I used the link in one of the comments
> (https://dev-builds.libreoffice.org/daily/master/current.html) and chose
> "Win-x86_64@tb77-TDF  2023-09-15 05:28:33".  I'll try to find a debug
> version.  Do you have a link I should follow?  I would be happy to run it
> again....

That's a version *without* debug symbols. The one with debug symbols is Win-x86@39. It can be used with Windbg per https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#First_Time_Setup

"Alternatively if you wish to also debug both the standard build and master build (Win-x86@39 tinderbox), paste the following instead" etc.
Comment 57 Barry L. Kramer 2023-09-18 06:26:54 UTC
(In reply to Mike Kaganski from comment #51)
> 
> Do you use some accessibility software?

Nice catch, Mike!

YES I am, and THAT is a prerequisite condition to the hang.

I use Windows Speech Recognition, the windows built-in dictation software. Based on your excellent question, I tested to see if the hang follows any of the related settings and it does.

In Settings > Accessibility > Speech (under the heading Interaction), the setting "Windows Speech Recognition", when On causes the hang to appear, and when Off causes it to go away. I observed that after setting it Off, a restart might be required, and when set back On, the hang might not happen on the very first cell copy, but it will in the first few.

This accessibility setting, when On, lets the user close or minimize the speech to text input tool which can be launched manually with Windows logo key + H. Whether that is present or not, or used or not, does not seem related.  Only the control panel setting is.

Hopefully this discovery will allow a developer to reproduce the problem. It certainly explains why it affects so few users.
Comment 58 Michael Weghorn 2023-09-18 14:24:51 UTC
I can reproduce on Windows 10 (Version 22H2 (OS Build 19045.3448)) as well.

At first glance, it looks like Windows Speech Recognition tries to iterate over all of the cells of the table (or maybe "just" over the first 2147483648 ones, since that's the max amount that the 32-bit API allows to return in `CMAccessible::get_accChildCount`, or whatever other limit Windows Speech Recognition or some library underneath have).

With a breakpoint in `CMAccessible::get_accChild` [1], I see this getting called  e.g. with `varChild.lVal = 1141`, then `varChild.lVal = 1142`, etc. And after letting it run for a while with `varChild.lVal = 3694`, then `varChild.lVal = 3695`,... Backtrace below.

I can't see anything obviously wrong on LO side here, it seems to be getting requests via the accessibility API that it is handling correctly.

Without knowing any further details on what Windows Speech Recognition is doing here, it's hard to further analyze this and I tend to think that Windows Speech Recognition shouldn't be requesting all of the cells (accessible children of the table).

Can you please report this issue to Microsoft as well and report back here if you get any reply from them?


Backtrace:                                                                       
                                                                          
1  CMAccessible::get_accChild        MAccessible.cxx  333  0x7fff7ba4b1ac 
2  CreateStdAccessibleProxyW         OLEACC                0x7fff93119f07 
3  UiaReturnRawElementProvider       uiautomationcore      0x7fff965938de 
4  UiaReturnRawElementProvider       uiautomationcore      0x7fff96594211 
5  UiaReturnRawElementProvider       uiautomationcore      0x7fff965939e8 
6  UiaReturnRawElementProvider       uiautomationcore      0x7fff96598f40 
7  UiaReturnRawElementProvider       uiautomationcore      0x7fff9659b407 
8  UiaGetReservedMixedAttributeValue uiautomationcore      0x7fff965bb46c 
9  DllCanUnloadNow                   uiautomationcore      0x7fff965760fe 
10 UiaClientsAreListening            uiautomationcore      0x7fff965aa999 
11 UiaGetReservedMixedAttributeValue uiautomationcore      0x7fff965b52e6 
12 UiaGetReservedMixedAttributeValue uiautomationcore      0x7fff965b44f1 
13 UiaGetReservedMixedAttributeValue uiautomationcore      0x7fff965b3058 
14 UiaClientsAreListening            uiautomationcore      0x7fff965ab2b8 
15 DllCanUnloadNow                   uiautomationcore      0x7fff965760fe 
16 UiaClientsAreListening            uiautomationcore      0x7fff965aa999 
17 UiaLookupId                       uiautomationcore      0x7fff9658d91e 
18 UiaLookupId                       uiautomationcore      0x7fff9658d744 
19 uiautomationcore                                        0x7fff96567300 
20 uiautomationcore                                        0x7fff96563c9c 
21 DllCanUnloadNow                   uiautomationcore      0x7fff965760fe 
22 DllCanUnloadNow                   uiautomationcore      0x7fff9657c997 
23 DllCanUnloadNow                   uiautomationcore      0x7fff9657c0e9 
24 uiautomationcore                                        0x7fff9656acf7 
25 UiaReturnRawElementProvider       uiautomationcore      0x7fff9659db15 
26 UiaReturnRawElementProvider       uiautomationcore      0x7fff9659d7d7 
27 Ordinal2712                       USER32                0x7fffade2e062 
28 SendMessageTimeoutW               USER32                0x7fffade30c93 
29 KiUserCallbackDispatcher          ntdll                 0x7fffaf850cd4 
30 NtUserGetMessage                  win32u                0x7fffad2c1104 
31 GetMessageW                       USER32                0x7fffade31c0e 
32 ImplSalYield                      salinst.cxx      531  0x7fff641c03da 
33 WinSalInstance::DoYield           salinst.cxx      580  0x7fff641bfe01 
34 ImplYield                         svapp.cxx        377  0x7fff674a7934 
35 Application::Yield                svapp.cxx        462  0x7fff674ab8a2 
36 Application::Execute              svapp.cxx        355  0x7fff674a4c5a 
37 desktop::Desktop::Main            app.cxx          1601 0x7fff7b3c96c2 
38 ImplSVMain                        svmain.cxx       204  0x7fff674bd1bc 
39 SVMain                            svmain.cxx       237  0x7fff674bda22 
40 soffice_main                      sofficemain.cxx  94   0x7fff7b418232 
41 sal_main                          main.c           51   0x7ff787e61013 
42 main                              main.c           49   0x7ff787e6105a 
43 invoke_main                       exe_common.inl   79   0x7ff787e61459 
44 __scrt_common_main_seh            exe_common.inl   288  0x7ff787e6137e 
45 __scrt_common_main                exe_common.inl   331  0x7ff787e6123e 
46 mainCRTStartup                    exe_main.cpp     17   0x7ff787e614ce 
47 BaseThreadInitThunk               KERNEL32              0x7fffae6c7344 
48 RtlUserThreadStart                ntdll                 0x7fffaf8026b1 


[1] https://git.libreoffice.org/core/+/b47a69ebee54a4b399c90311e17b994635140002/winaccessibility/source/UAccCOM/MAccessible.cxx#333

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6f60670877208612b5ea320b3677480ef6508abb
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded
Comment 59 Judith 2023-09-29 18:44:29 UTC
Thank you all for identifying this. I turned off the speech recognition program quite a while ago  and did not even remember I had enabled it in Settings. My problem is solved. I appreciate all your work on this.
Comment 60 Mike Kaganski 2023-09-29 19:09:27 UTC
(In reply to Michael Weghorn from comment #58)
> At first glance, it looks like Windows Speech Recognition tries to iterate
> over all of the cells of the table (or maybe "just" over the first
> 2147483648 ones, since that's the max amount that the 32-bit API allows to
> return in `CMAccessible::get_accChildCount`, or whatever other limit Windows
> Speech Recognition or some library underneath have).
> 
> ...
> 
> I can't see anything obviously wrong on LO side here, it seems to be getting
> requests via the accessibility API that it is handling correctly.

I /suspect/ that the API [1] assumes (or allows) the get_accChildCount to return a number only reflecting *visible* children. In this case, scrolling would generate EVENT_OBJECT_CREATE and EVENT_OBJECT_DESTROY events.

If you create a test program for texting what Excel reports - the number of accessible children, and maybe which are those - I could test locally for you, and report back, to confirm / reject this suspicion.

[1] https://learn.microsoft.com/en-us/windows/win32/api/oleacc/nf-oleacc-iaccessible-get_accchildcount
Comment 61 Michael Weghorn 2023-09-29 19:35:31 UTC
(In reply to Mike Kaganski from comment #60)
> I /suspect/ that the API [1] assumes (or allows) the get_accChildCount to
> return a number only reflecting *visible* children. In this case, scrolling
> would generate EVENT_OBJECT_CREATE and EVENT_OBJECT_DESTROY events.

Thanks. I just tested Excel (LTSC 2021) with NVDA's interactive Python console (move mouse over cell, then Insert+Ctrl+Z to open the console) and the result is "interesting". Excel doesn't seem to allow the "usual" way to access the children at all:

> >>> mouse.name
> ''
> >>> mouse.role
> <Role.TABLECELL: 29>
> >>> mouse.parent
> <NVDAObjects.window.excel.ExcelWorksheet object at 0x043BEDD0>
> >>> sheet = mouse.parent
> >>> sheet.childCount
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\__init__.pyc", line 1002, in _get_childCount
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\__init__.pyc", line 709, in _get_children
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\window\excel.pyc", line 898, in _get_firstChild
>   File "monkeyPatches\comtypesMonkeyPatches.pyc", line 87, in new__getattr__
>   File "comtypes\client\lazybind.pyc", line 168, in __getattr__
>   File "comtypes\automation.pyc", line 746, in _invoke
>   File "monkeyPatches\comtypesMonkeyPatches.pyc", line 32, in __call__
> _ctypes.COMError: (-2147418111, 'Call was rejected by callee.', (None, None, None, 0, None))
> >>> sheet.childCount
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\__init__.pyc", line 1002, in _get_childCount
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\__init__.pyc", line 709, in _get_children
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\window\excel.pyc", line 898, in _get_firstChild
>   File "monkeyPatches\comtypesMonkeyPatches.pyc", line 87, in new__getattr__
>   File "comtypes\client\lazybind.pyc", line 168, in __getattr__
>   File "comtypes\automation.pyc", line 746, in _invoke
>   File "monkeyPatches\comtypesMonkeyPatches.pyc", line 32, in __call__
> _ctypes.COMError: (-2147418111, 'Call was rejected by callee.', (None, None, None, 0, None))
> >>> sheet.children
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\__init__.pyc", line 709, in _get_children
>   File "baseObject.pyc", line 62, in __get__
>   File "baseObject.pyc", line 168, in _getPropertyViaCache
>   File "NVDAObjects\window\excel.pyc", line 898, in _get_firstChild
>   File "monkeyPatches\comtypesMonkeyPatches.pyc", line 87, in new__getattr__
>   File "comtypes\client\lazybind.pyc", line 168, in __getattr__
>   File "comtypes\automation.pyc", line 746, in _invoke
>   File "monkeyPatches\comtypesMonkeyPatches.pyc", line 32, in __call__
> _ctypes.COMError: (-2147418111, 'Call was rejected by callee.', (None, None, None, 0, None))
> >>> sheet.getChild(0)

There's also tdf#156657 about potentially limiting the amount of Calc cells to expose via a11y API, but that is currently waiting for feedback on what would be a proper way to do so. (I'm hesitant about the idea of just doing something without documentation on what's a proper way.)

I've heard several times that in general, exposing only on-screen children is not great, since it e.g. breaks having a screen reader read out a whole document. (This is currently a problem with Writer, s. tdf#96492).

Right now, I don't see a clear way forward on LO side and in my opinion, a11y clients like Windows Speech Recognition should also properly handle many children, so I think this should at least be reported to Microsoft.

[1] and [2] are cases where something similar was addressed for NVDA and AT-SPI, but unfortunately, Windows Speech Recognition is closed source.

[1] https://github.com/nvaccess/nvda/commit/0170323c19275febbaf6698f9d2aae68cafe571b
[2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/138
Comment 62 ericbresslermd 2023-11-17 15:42:28 UTC
I was the original reporter of this bug. When someone noticed a conflict with Windows Speech Recognition, I checked my own configuration. It was turned off. When I turned it on and then off again, the problem with Copy causing LibreOffice 7.4 to freeze disappeared. It has not reoccurred in a month since then. Thanks for posting about this conflict!
Comment 63 QA Administrators 2023-11-18 03:13:14 UTC Comment hidden (obsolete)
Comment 64 Barry L. Kramer 2023-11-18 08:54:14 UTC
That is a strange automated change of the status of this issue.

That aside, did anyone who worked on this reproduce my observation that the problem did not occur if Calc was launched from the command line?  For me, it only happened when run from the windows shortcut.  Maybe this is just something simple like the command line invoke didn't run the Speech feature at all, but I did want to mention it because e.g. if that feature were still launched but it got started up in a different way such that CMAccessible::get_accChildCount doesn't return 2147483648 but rather something meaningful, maybe that could lead somewhere.

I will test it again but need to restart... LO won't launch at all
Comment 65 Barry L. Kramer 2023-11-18 12:49:03 UTC
I was having problems with LO 7.6.2 Calc and Writer not starting at all (the splash screen came up but then went away, not launching) so I uninstalled.  On reinstall of 7.5.0 and then 7.5.4.2, I can no longer reproduce the original problem even when the windows speech recognition is enabled.  Strange.  current OS:

Edition	Windows 11 Home
Version	22H2
Installed on	‎2/‎22/‎2023
OS build	22621.2428
Experience	Windows Feature Experience Pack 1000.22674.1000.0
Comment 66 ericbresslermd 2023-11-18 16:55:28 UTC
(In reply to Barry L. Kramer from comment #64)
> That is a strange automated change of the status of this issue.
> 
> That aside, did anyone who worked on this reproduce my observation that the
> problem did not occur if Calc was launched from the command line?  For me,
> it only happened when run from the windows shortcut.  Maybe this is just
> something simple like the command line invoke didn't run the Speech feature
> at all, but I did want to mention it because e.g. if that feature were still
> launched but it got started up in a different way such that
> CMAccessible::get_accChildCount doesn't return 2147483648 but rather
> something meaningful, maybe that could lead somewhere.
> 
> I will test it again but need to restart... LO won't launch at all

Your command line workaround worked well for me. Of course now that the program is working properly after toggling on and off the speech recognition, I'm no longer using the workaround.
Comment 67 ady 2023-12-28 11:14:22 UTC
I have to admit that I don't understand why this report is still set as unconfirmed.

More than one user in this report has reported problems with copying a cell in Calc when Windows' Speech Recognition is ON.

Additional points:

* Speech Recognition might not be the only conflicting Windows' feature triggering a freeze in Calc when copying a cell (e.g. Windows 11's "Suggested Actions" might also be a cause, mentioned in other reports and in ask.lo.org, and/or Windows' Clipboard History).

* The conflict might be reproduced with some LO versions but maybe not with others.

* A possible workaround (according to at least one comment) could be to set Windows' Speech Recognition to OFF. Also possible: setting Windows' Speech Recognition back to ON might not trigger the problem; rebooting in-between might be part of the steps to try. YMMV.

* Whether the problem is _consistently_ reproduced or not, it _is_ being reproduced, and users might keep blaming LO, so the conflict should rather be investigated and solved (instead of simply staying passive and claiming some possible "not-our-bug").
Comment 68 Mike Kaganski 2023-12-28 11:41:05 UTC
(In reply to ady from comment #67)
> ... so the conflict should rather
> be investigated and solved (instead of simply staying passive and claiming
> some possible "not-our-bug").

Using this passive voice, do you mean that the conflict should do something itself; or do you actually assign someone? Meaning, that you likely have power to tell some volunteer developer to start working on this and that?

Phrases like that are useless, and in fact rude. This bug wasn't set "NOTOURBUG", nor any other "we won't work on it" resolution. You have a point that it should be NEW - go ahead and change the status, since it is enough a single independent reproducing report, and a confirmation that it is indeed a problem (rather than expected behavior - which is obvious in this case), to mark it as such.
Comment 69 ady 2023-12-28 12:13:26 UTC
(In reply to Mike Kaganski from comment #68)
> (In reply to ady from comment #67)
> > ... so the conflict should rather
> > be investigated and solved (instead of simply staying passive and claiming
> > some possible "not-our-bug").
> 
> Using this passive voice, do you mean that the conflict should do something
> itself; or do you actually assign someone? Meaning, that you likely have
> power to tell some volunteer developer to start working on this and that?
> 
> Phrases like that are useless, and in fact rude. This bug wasn't set
> "NOTOURBUG", nor any other "we won't work on it" resolution. You have a
> point that it should be NEW - go ahead and change the status, since it is
> enough a single independent reproducing report, and a confirmation that it
> is indeed a problem (rather than expected behavior - which is obvious in
> this case), to mark it as such.

@Mike, I didn't mean that.

After several comments and even dupes, the report is still set as unconfirmed. That seems strange to me, and I don't understand why. In that context, it would look as a passive attitude, in the sense of the practical consequence. But perhaps there is a reason not to set it as new(?).

Sometimes, when "a group" shares something (as oppose to one person in particular), then no one actually takes responsibility or action or cares enough to do something (e.g. wasting energy in a public place).

Regarding my "not-our-bug" comment, it is just a possibility, that some would suggest such status (considering that it is not set to new, and I still don't know why). Since the report was/is not set to new, maybe someone would think that all these symptoms should rather be solved by MS. Maybe the problem is really not at all a bug in LO, but IMHO it would be better to try to find some way to make it work anyway, for the reasons I mentioned before in my prior comment.

I don't see anything rude in that. On the contrary, it is a humble and respectful "ping" about this report (starting by sincerely asking for the possible reasons for this report not to be set as new, with an attempt to summarize the current situation), but maybe I am too naive.
Comment 70 Buovjaga 2023-12-28 13:14:15 UTC
(In reply to ady from comment #67)
> I have to admit that I don't understand why this report is still set as
> unconfirmed.

Look at the history and you will see why: https://bugs.documentfoundation.org/show_activity.cgi?id=153131

The automatic script always sets from NEEDINFO to UNCONFIRMED after someone comments. It doesn't check what the status was before needinfo (in this case it was NEW).
Comment 71 Stéphane Guillou (stragu) 2023-12-28 14:04:49 UTC
Settings to "high - major" as it's a freeze from a common operation.

Michael, Mike: do you think this is the same source cause as a memory increase when "offer suggested actions" is on? See bug 158691 and ady's comment 67.
Comment 72 Michael Weghorn 2023-12-28 14:37:20 UTC
(In reply to Stéphane Guillou (stragu) from comment #71)
> Settings to "high - major" as it's a freeze from a common operation.
> 
> Michael, Mike: do you think this is the same source cause as a memory
> increase when "offer suggested actions" is on? See bug 158691 and ady's
> comment 67.

See comment 58, comment 60 and comment 61 for a first analysis and the potential cause of the freeze. (Speech recognition querying an insane amount of children/cells.)

(In reply to ady from comment #69)
> Regarding my "not-our-bug" comment, it is just a possibility, that some
> would suggest such status (considering that it is not set to new, and I
> still don't know why). Since the report was/is not set to new, maybe someone
> would think that all these symptoms should rather be solved by MS. Maybe the
> problem is really not at all a bug in LO, but IMHO it would be better to try
> to find some way to make it work anyway, for the reasons I mentioned before
> in my prior comment.

As mentioned in comment 61, I still think it would be worth trying to report to Microsoft at least, and see whether they can/will do anything about it.

[My hope was that somebody with particular interest in this bug would go ahead and do this, but if nobody else is interested in doing that, I can add that to my list of things to do at some point next year.]

It may be they don't. And I don't say that the LO side shouldn't change, but as described in more detail in the above-mentioned comments, I currently don't see a straightforward way to avoid the problem without the risk of breaking other use cases.

Of course, if anybody has any great idea, please don't hesitate to implement that (or at least mention it here), but at least my main focus so far was on more actionable things, while this one here was mostly one of the "wait for further input and potentially revisit later" kind.

The discussion in https://gitlab.gnome.org/GNOME/gtk/-/issues/6204 might provide some helpful input (see in particular the comments from the Orca maintainer, Joanmarie Diggs), but that's also still ongoing.