Bug 105712 - With NVDA active launching Special Character dialog using Insert -> Special Character, or via F7 Spell check causes a fatal error. With using Standard Toolbar button it also hangs but without crash.
Summary: With NVDA active launching Special Character dialog using Insert -> Special ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.2.6 target:5.3.1
Keywords: bibisected, bisected, haveBacktrace
Depends on:
Blocks: a11y-Windows
  Show dependency tree / graph
 
Reported: 2017-02-02 18:28 UTC by am_dxer
Modified: 2017-02-16 13:01 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:

Attachments
WinDbg 64-bit w symbols StackTrace of DMP taken via Taskmanager (36.86 KB, text/plain)
2017-02-13 19:49 UTC, V Stuart Foote 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description am_dxer 2017-02-02 18:28:21 UTC 
Description:
After launching the Spell Checker, if I tab to the Special character button and select it, LibreOffice crashes with a fatal error dialog.

Steps to Reproduce:
1. Open the Spell Check dialog
2. Tab to the Special Character button.
3. Press Enter to activate the button

Actual Results:  
The program crashes

Expected Results:
The program should not crash


Reproducible: Always

User Profile Reset: Yes

Additional Info:
Tested with nightly build of master on Windows 7


User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
Comment 1 Xisco Faulí 2017-02-02 18:37:52 UTC 
I can't reproduce it in

Version: 5.4.0.0.alpha0+
Build ID: fc53cce64400430cdc21f79c959d75fb9a26d13d
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: x11; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 2 am_dxer 2017-02-02 18:40:16 UTC 
I forgot to mansion one step. When focus with tab lands on the Paste button, you have to press the right arrow to focus the Special Character button.
Comment 3 am_dxer 2017-02-02 18:53:56 UTC 
I have the issue in:
Version: 5.4.0.0.alpha0+
Build ID: d7736283aae4a79aa497bd2196a076ff402e671f
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-02_00:30:31
Locale: en-US (en_US); Calc: group
Comment 4 Xisco Faulí 2017-02-02 22:20:58 UTC 
(In reply to am_dxer from comment #2)
> I forgot to mansion one step. When focus with tab lands on the Paste button,
> you have to press the right arrow to focus the Special Character button.

In my case, tab never lands on the paste button. Could you please record a screencast ?
Comment 5 am_dxer 2017-02-03 12:30:39 UTC 
Hello,
I am blind so a screen cast is difficult. I do think the version you tested with  is too old to reproduce this bug. The commit that caused the bug occurred only a day ago. Can you try with the latest version of master?
Comment 6 am_dxer 2017-02-03 12:47:15 UTC 
I can reproduce it as well in:
Version: 5.4.0.0.alpha0+
Build ID: 789ed159fb03eef26c991f361380d0eb7b509cd9
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-03_01:06:06
Locale: en-US (en_US); Calc: group
Comment 7 Julien Nabet 2017-02-05 11:17:54 UTC 
On pc Debian x86-64 with master sources updated today + gen rendering, I don't reproduce this.

Do you reproduce this on a brand new empty document or with a specific document?
If specific, would it be possible you attach it by using this link:
https://bugs.documentfoundation.org/attachment.cgi?bugid=105712&action=enter
?
(have in mind that any attachment is automatically made public, so remove any private/confidential part from it)

It could be useful to retrieve a backtrace by following this link:
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace
Comment 8 am_dxer 2017-02-07 12:16:38 UTC 
I tested this on Linux and can confirm that the bug does not appear on Linux. I could reproduce it on two Windows machines.
Comment 9 am_dxer 2017-02-13 15:46:16 UTC 
Can anyone reproduce this on Windows?
Comment 10 Xisco Faulí 2017-02-13 15:59:41 UTC 
I can't reproduce it in

Versión: 5.3.0.3
Id. de compilación: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
Subpr. de CPU: 1; Versión de SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; 
Configuración regional: es-ES (es_ES); Calc: group
Comment 11 am_dxer 2017-02-13 16:16:02 UTC 
This bug doesn't exist in 5.3. Can you try with a tinderbox build of 5.4?
Comment 12 Xisco Faulí 2017-02-13 16:18:14 UTC 
(In reply to am_dxer from comment #11)
> This bug doesn't exist in 5.3. Can you try with a tinderbox build of 5.4?

The special character dialog is open when pressing OK in

Version: 5.4.0.0.alpha0+
Build ID: a296a69c984b17cfbcd249cf6bdc191d08dff2a6
CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-06_00:00:55
Locale: es-ES (es_ES); Calc: group
Comment 13 am_dxer 2017-02-13 16:43:26 UTC 
That should be new enough. The commit that causes this problem was in response to bugg 100438. Before that, the Special Character button was not in the tab order. Could you explain more clearly what you mean by pressing the OK Button, To reproduce this, I first open the spell check dialog. Next I use the Shift+Tab key and focus is placed in the edit box for making a correction. Next, I press Shift+Tab again, my screen reader NVDA says "Toolbar, Special Character button". I do not press an OK button at any time during the steps that cause a crash. I will add a11y to this in case its only an accessibility bug.
Comment 14 Xisco Faulí 2017-02-13 16:56:41 UTC 
Sorry, I meant press key instead of OK...

I can reproduce it when NVDA is running

Version: 5.4.0.0.alpha0+
Build ID: a296a69c984b17cfbcd249cf6bdc191d08dff2a6
CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-06_00:00:55
Locale: es-ES (es_ES); Calc: group
Comment 15 V Stuart Foote 2017-02-13 19:49:59 UTC 
Created attachment 131194 [details]
WinDbg 64-bit w symbols StackTrace of DMP taken via Taskmanager

Confirming on Windows 8.1 Ent 64-bit en-US with AT NVDA 2016.4 screen reader active and
Version: 5.3.0.3 (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

STR as reported. 

1. NVDA a11y screen reader enabled and sounding
2. New Writer document with a few typos.
3. F7 to launch spell check dialog
4. select first mispelling, the "Special Character" button activates
5. select the "Special Character" button action
6. immediate message dialog "LibreOffice 5.3 - Fatal Error"
7. use Taskmanager to "Create dump file"
8. OK to close LibreOffice
9. Open the DMP file in WinDbg and pull StackTrace with "~* kp"
10. run "analyze -v" against the DMP.

Attaching StackTrace (here) and next the DMP file, below is WinDbg analyze -v of the DMP file. Look to be hitting a breakpoint. For some reason, with NVDA running the google_breakpad::ExceptionHandler::ExceptionHandlerThreadMain does not run.

Disabling NVDA 2016.4 and repeating a new document with spelling errors, F7 and the Special Character dialog immediately pops-open and can be selected.

=-WinDbg analyze -v of crash dump-=

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\gof509\AppData\Local\Temp\soffice (3).DMP]
User Mini Dump File with Full Memory: Only application data is available

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
+8bcad30650
00000000`00000000 ??              ???

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

CONTEXT:  0000000000000000 -- (.cxr 0x0;r)
rax=0000000000000040 rbx=0000000000000000 rcx=00007ff8f2fde51b
rdx=00007ff8f1120000 rsi=0000000000000001 rdi=00000000002e09e6
rip=00007ff91bad104a rsp=0000004c92d9b918 rbp=0000004c936ae9e0
 r8=0000000000000000  r9=0000000000000000 r10=0000004c92d9b680
r11=0000004c92d88000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000001 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
user32!NtUserWaitMessage+0xa:
00007ff9`1bad104a c3              ret

FAULTING_THREAD:  0000000000000b24

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  _socket.pyd

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  _socket.pyd

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

LAST_CONTROL_TRANSFER:  from 00007ff91bb05b77 to 00007ff91bad104a

STACK_TEXT:  
0000004c`92d9b918 00007ff9`1bb05b77 : 00000000`00000000 0000004c`936ae9e0 00000000`00000001 00000000`00000001 : user32!NtUserWaitMessage+0xa
0000004c`92d9b920 00007ff9`1bb076e2 : 00000000`00000000 00007ff9`1bb08b10 00000000`00000000 00007ff9`1badb7cd : user32!DialogBox2+0x212
0000004c`92d9b9b0 00007ff9`1bb099a2 : 00000000`00010005 0000004c`92d9bae9 0000004c`92d9bd20 00000000`00000000 : user32!InternalDialogBox+0x132
0000004c`92d9ba10 00007ff9`1bb0913d : 00007ff9`000000c4 00007ff9`00000103 0000004c`a4156590 00000000`00000001 : user32!SoftModalMessageBox+0xee1
0000004c`92d9bb50 00007ff9`1bb581ba : 00007ff9`0904e188 00000000`00000000 0000004c`9d39c6d0 00007ff9`0902c018 : user32!MessageBoxWorker+0x2eb
0000004c`92d9bd00 00007ff9`1bb5822e : 00007ff8`f2c0c70a 00007ff8`f2fd995e 0000004c`9d39c6d0 0000004c`9d34b870 : user32!MessageBoxTimeoutW+0xba
0000004c`92d9be00 00007ff8`f1f71ce4 : 0000004c`92d9e450 00000000`00000000 0000004c`92d9e450 0000004c`92fc99a0 : user32!MessageBoxW+0x4e
0000004c`92d9be40 00007ff8`f3cb88dc : 00000000`00000000 0000004c`9d34b868 0000004c`9d39c6c8 00007ff9`0f4e3403 : mergedlo!desktop::`anonymous namespace'::FatalError+0x114
0000004c`92d9bea0 00007ff9`0f526920 : 00007ff8`f3cb88b5 0000004c`92d9f520 0000004c`92d9f520 00000000`00000000 : mergedlo!`desktop::Desktop::Main'::`1'::catch$2+0x27
0000004c`92d9bef0 00007ff9`0f51e36d : 00007ff8`f3cb88b5 0000004c`92d9d268 00000000`00000100 00000000`00000000 : msvcr120!_CallSettingFrame+0x20
0000004c`92d9bf20 00007ff9`1bce2a63 : 00000000`00000000 0000004c`92d9e2e0 00000000`00000000 00000000`00000000 : msvcr120!__CxxCallCatchBlock+0xf5
0000004c`92d9bff0 00007ff8`f1f74c99 : 0000004c`00000000 0000004c`96c79718 00000000`00000000 00000000`00000000 : ntdll!RcConsolidateFrames+0x3
0000004c`92d9f520 00007ff8`f2f1062e : 0000004c`95811530 00000000`00000000 00000000`00000001 00007ff8`f582f720 : mergedlo!desktop::Desktop::Main+0x10f9
0000004c`92d9f7a0 00007ff8`f2f109d2 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : mergedlo!ImplSVMain+0x6e
0000004c`92d9f7e0 00007ff8`f1f92cfd : 00000000`00000000 00000000`00000001 0000004c`93175328 00000000`00000000 : mergedlo!SVMain+0x32
0000004c`92d9f810 00007ff7`4151102e : 0000004c`92f44350 00007ff9`1bc557d0 0000004c`92f237c5 00000000`00000001 : mergedlo!soffice_main+0x11d
0000004c`92d9fa60 00007ff7`4151139d : 0000004c`92f237c3 00000000`00000001 00000000`00000001 00000000`00000000 : soffice+0x102e
0000004c`92d9fa90 00007ff9`193a13d2 : 00007ff7`41511240 00007ff7`40c6c000 00000000`00000000 00000000`00000000 : soffice!main+0x35d
0000004c`92d9fad0 00007ff9`1bc654e4 : 00007ff9`193a13b0 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x22
0000004c`92d9fb00 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x34


STACK_COMMAND:  ~0s; .ecxr ; kb

FOLLOWUP_IP: 
mergedlo!`desktop::Desktop::Main'::`1'::catch$2+27 [c:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\app.cxx @ 1697]
00007ff8`f3cb88dc 90              nop

FAULTING_SOURCE_LINE:  c:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\app.cxx

FAULTING_SOURCE_FILE:  c:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\app.cxx

FAULTING_SOURCE_LINE_NUMBER:  1697

SYMBOL_STACK_INDEX:  8

SYMBOL_NAME:  mergedlo!`desktop::Desktop::Main'::`1'::catch$2+27

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: mergedlo

IMAGE_NAME:  mergedlo.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  588aff17

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_mergedlo.dll!_desktop::Desktop::Main_::_1_::catch$2

BUCKET_ID:  APPLICATION_FAULT_STATUS_BREAKPOINT_mergedlo!_desktop::Desktop::Main_::_1_::catch$2+27

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:status_breakpoint_80000003_mergedlo.dll!_desktop::desktop::main_::_1_::catch$2

FAILURE_ID_HASH:  {bbe234ab-30de-fc54-9338-6cfc4773366d}

Followup: MachineOwner
---------
Comment 16 V Stuart Foote 2017-02-13 20:27:52 UTC 
This is Windows only while the NVDA screen reader 2016.4 (or 2016.3) is enabled and sounding.

Launching Special Character dialog button,  Insert -> Special Character, or via F7 Spell check causes a fatal error.  While using the Standard toolbar "Special Character" button hangs the UI but without the error popup although the Breakpad Exception Handler is kicked off.

Any chance of the Python instances coliding?

=-WinDbg 64 while using Standard TB button-=

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
+8920be9660
00000000`00000000 ??              ???

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

CONTEXT:  0000000000000000 -- (.cxr 0x0;r)
rax=00007ff8f582f720 rbx=0000008060b5f440 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000001 rdi=0000000000000000
rip=00007ff91bad26ba rsp=0000008060b5f3d8 rbp=0000000000000000
 r8=0000008060b5f3d8  r9=0000000000000000 r10=0000000000000000
r11=0000000000000246 r12=0000000000000000 r13=0000000000000001
r14=0000000000000000 r15=0000000000001244
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
user32!NtUserGetMessage+0xa:
00007ff9`1bad26ba c3              ret

FAULTING_THREAD:  0000000000001244

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  _socket.pyd

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  _socket.pyd

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

LAST_CONTROL_TRANSFER:  from 00007ff91bad2685 to 00007ff91bad26ba

STACK_TEXT:  
00000080`60b5f3d8 00007ff9`1bad2685 : 00000000`00000000 00007ff9`18e4155c ffffffff`fffffffe 00007ff8`f2f0f42c : user32!NtUserGetMessage+0xa
00000080`60b5f3e0 00007ff8`f2fddf89 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : user32!GetMessageW+0x25
00000080`60b5f410 00007ff8`f2fddcf1 : 00000000`00000001 00000000`00000001 00000000`00000206 00007ff8`f2fddc1f : mergedlo!ImplSalYield+0xc9
00000080`60b5f480 00007ff8`f2f0a126 : 00000080`60d752f0 00007ff8`f582f720 00000000`00000000 00000080`60cd1ba0 : mergedlo!WinSalInstance::DoYield+0xf1
00000080`60b5f4e0 00007ff8`f2f0871d : 00000080`66885400 00000080`6aec0420 00007ff9`09053750 00000080`60d75440 : mergedlo!ImplYield+0x86
00000080`60b5f540 00007ff8`f1f74c99 : 00000080`00000000 00000080`64a29718 00000000`00000000 00000000`00000000 : mergedlo!Application::Execute+0x13d
00000080`60b5f5a0 00007ff8`f2f1062e : 00000080`635312b0 00000000`00000000 00000000`00000001 00007ff8`f582f720 : mergedlo!desktop::Desktop::Main+0x10f9
00000080`60b5f820 00007ff8`f2f109d2 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : mergedlo!ImplSVMain+0x6e
00000080`60b5f860 00007ff8`f1f92cfd : 00000000`00000000 00000000`00000001 00000080`60f35328 00000000`00000000 : mergedlo!SVMain+0x32
00000080`60b5f890 00007ff7`4151102e : 00000080`60cf4350 00007ff9`1bc557d0 00000080`60cd37c5 00000000`00000001 : mergedlo!soffice_main+0x11d
00000080`60b5fae0 00007ff7`4151139d : 00000080`60cd37c3 00000000`00000001 00000000`00000001 00000000`00000000 : soffice+0x102e
00000080`60b5fb10 00007ff9`193a13d2 : 00007ff7`41511240 00007ff7`406ef000 00000000`00000000 00000000`00000000 : soffice!main+0x35d
00000080`60b5fb50 00007ff9`1bc654e4 : 00007ff9`193a13b0 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x22
00000080`60b5fb80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x34


STACK_COMMAND:  ~0s; .ecxr ; kb

FOLLOWUP_IP: 
mergedlo!ImplSalYield+c9 [c:\cygwin64\home\buildslave\source\libo-core\vcl\win\app\salinst.cxx @ 602]
00007ff8`f2fddf89 85c0            test    eax,eax

FAULTING_SOURCE_LINE:  c:\cygwin64\home\buildslave\source\libo-core\vcl\win\app\salinst.cxx

FAULTING_SOURCE_FILE:  c:\cygwin64\home\buildslave\source\libo-core\vcl\win\app\salinst.cxx

FAULTING_SOURCE_LINE_NUMBER:  602

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  mergedlo!ImplSalYield+c9

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: mergedlo

IMAGE_NAME:  mergedlo.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  588aff17

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_mergedlo.dll!ImplSalYield

BUCKET_ID:  APPLICATION_FAULT_STATUS_BREAKPOINT_mergedlo!ImplSalYield+c9

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:status_breakpoint_80000003_mergedlo.dll!implsalyield

FAILURE_ID_HASH:  {bfc47c5c-6d65-cfef-e6c1-f325ca858a1a}

Followup: MachineOwner
---------
Comment 17 V Stuart Foote 2017-02-13 21:02:07 UTC 
Issue of hanging the LO UI opening the Special Character dialog are present "with NVDA running" on earlier builds of 5.x, no crash noted on a 4.4 install.

Setting bibisect request.

@Jamie - reluctant to NOB this, but any thoughts on why this would only happen with NVDA active and sounding?

=-Tested-=

LO hangs with NVDA 2016.4 with Windows 8.1 Ent 64-bit with these builds.

Version: 5.3.0.0.beta2+ (x64)
Build ID: 371f0f6770add78ae81e0f769d0490874bca353c
CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-5-3, Time: 2016-12-22_13:59:31
Locale: en-US (en_US); Calc: CL

9 Jun 2016
Version: 5.3.0.0.beta2 (x64)
Build ID: a7e30712ad6d8bc9286007b37aa581983e0caba3
CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: CL

31 Oct 2016
Version: 5.2.3.3 (x64)
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; 
Locale: en-US (en_US); Calc: CL

5 May 2016
Version: 5.0.6.3 (x64)
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
Locale: en-US (en_US)
Comment 18 James Teh 2017-02-14 00:31:59 UTC 
NVDA is nowhere in the call stack here, so this is almost certainly not related to NVDA code. Most likely, it's a bug in the accessibility code (which doesn't run while NVDA isn't running, hence the lack of crash when NVDA isn't running).

Debugging this is painful because LO catches unhandled C++ exceptions and displays a fatal error dialog, but in WinDBG, we lose the exception that was caught (or at least, I don't know how to get to it). Catching first chance C++ exceptions helps, but there are quite a lot of them, so knowing which one triggered the fatal error is tricky. Any advice on this?

I *think* the following is the exception in question and it is indeed related to accessibility code. Here's the stack trace:

 # ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
00 0171e968 662b9339 KERNELBASE!RaiseException+0x62
01 0171e9a8 639231c2 msvcr120!_CxxThrowException(void * pExceptionObject = 0x0171e9c4, struct _s__ThrowInfo * pThrowInfo = 0x654eeb58)+0x5b [f:\dd\vctools\crt\crtw32\eh\throw.cpp @ 152]
02 0171e9e4 61cf637b mergedlo!svx::SvxShowCharSetVirtualAcc::getAccessibleChild(long i = 0n0)+0x172 [c:\cygwin64\home\buildslave\source\libo-core\svx\source\accessibility\charmapacc.cxx @ 131]
03 0171ea28 61cf63b0 winaccessibility!AccTopWindowListener::AddAllListeners(class com::sun::star::accessibility::XAccessible * pAccessible = 0x093741cc, class com::sun::star::accessibility::XAccessible * pParentXAcc = 0x09373c64, struct HWND__ * pWND = 0x000b0652)+0xfb [c:\cygwin64\home\buildslave\source\libo-core\winaccessibility\source\service\acctopwindowlistener.cxx @ 174]
04 0171ea6c 61cf63b0 winaccessibility!AccTopWindowListener::AddAllListeners(class com::sun::star::accessibility::XAccessible * pAccessible = 0x09373c64, class com::sun::star::accessibility::XAccessible * pParentXAcc = 0x093741cc, struct HWND__ * pWND = 0x000b0652)+0x130 [c:\cygwin64\home\buildslave\source\libo-core\winaccessibility\source\service\acctopwindowlistener.cxx @ 183]
05 0171eab0 61cf63b0 winaccessibility!AccTopWindowListener::AddAllListeners(class com::sun::star::accessibility::XAccessible * pAccessible = 0x09373c04, class com::sun::star::accessibility::XAccessible * pParentXAcc = 0x09373c64, struct HWND__ * pWND = 0x000b0652)+0x130 [c:\cygwin64\home\buildslave\source\libo-core\winaccessibility\source\service\acctopwindowlistener.cxx @ 183]
06 0171eaf4 61cf6529 winaccessibility!AccTopWindowListener::AddAllListeners(class com::sun::star::accessibility::XAccessible * pAccessible = 0x08d47320, class com::sun::star::accessibility::XAccessible * pParentXAcc = 0x09373c04, struct HWND__ * pWND = 0x000b0652)+0x130 [c:\cygwin64\home\buildslave\source\libo-core\winaccessibility\source\service\acctopwindowlistener.cxx @ 183]
07 0171eb38 61cf75ba winaccessibility!AccTopWindowListener::HandleWindowOpened(class com::sun::star::accessibility::XAccessible * pAccessible = 0x083998f8)+0xe9 [c:\cygwin64\home\buildslave\source\libo-core\winaccessibility\source\service\acctopwindowlistener.cxx @ 79]
08 0171eb64 63e4cebe winaccessibility!AccTopWindowListener::windowOpened(struct com::sun::star::lang::EventObject * e = 0x0171eba0)+0x6a [c:\cygwin64\home\buildslave\source\libo-core\winaccessibility\source\service\acctopwindowlistener.cxx @ 127]
09 0171ebb4 63e4e339 mergedlo!`anonymous namespace'::VCLXToolkit::callTopWindowListeners(class VclSimpleEvent * pEvent = 0x1402a090, <function> * pFn = 0x63e492a6)+0xde [c:\cygwin64\home\buildslave\source\libo-core\toolkit\source\awt\vclxtoolkit.cxx @ 1828]
0a 0171ebc4 63e4c08e mergedlo!`anonymous namespace'::VCLXToolkit::eventListenerHandler(class VclSimpleEvent * rEvent = 0x0171ec40)+0x29 [c:\cygwin64\home\buildslave\source\libo-core\toolkit\source\awt\vclxtoolkit.cxx @ 1793]
0b 0171ebd0 643d0090 mergedlo!`anonymous namespace'::VCLXToolkit::LinkStubeventListenerHandler(void * instance = 0x09f6ec08, class VclSimpleEvent * data = 0x0171ec40)+0xe [c:\cygwin64\home\buildslave\source\libo-core\toolkit\source\awt\vclxtoolkit.cxx @ 1754]
0c 0171ec10 643c80a7 mergedlo!VclEventListeners::Call(class VclSimpleEvent * rEvent = 0x0171ec40)+0xd0 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\vclevent.cxx @ 61]
0d 0171ec1c 64138d53 mergedlo!Application::ImplCallEventListeners(class VclSimpleEvent * rEvent = 0x0171ec40)+0x17 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svapp.cxx @ 839]
0e 0171ec98 641b2071 mergedlo!vcl::Window::CallEventListeners(unsigned long nEvent = 0x3eb, void * pData = 0x13f44258)+0x63 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\event.cxx @ 214]
0f 0171ecac 641b3dec mergedlo!vcl::Window::ImplSetReallyVisible(void)+0x61 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\window.cxx @ 1307]
10 0171ed08 64127122 mergedlo!vcl::Window::Show(bool bVisible = true, ShowFlags nFlags = NONE (0n0))+0x3ec [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\window.cxx @ 2314]
11 0171ed40 64125e50 mergedlo!Dialog::ImplStartExecuteModal(void)+0x172 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\dialog.cxx @ 832]
12 0171ed8c 5fa2cfd3 mergedlo!Dialog::Execute(void)+0x40 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\dialog.cxx @ 896]
13 0171edf4 60ab5741 cuilo!SvxCharacterMap::Execute(void)+0x33 [c:\cygwin64\home\buildslave\source\libo-core\cui\source\dialogs\cuicharmap.cxx @ 154]
14 0171eefc 60ab7d20 swlo!SwTextShell::InsertSymbol(class SfxRequest * rReq = 0x0171f49c)+0x3c1 [c:\cygwin64\home\buildslave\source\libo-core\sw\source\uibase\shells\textsh.cxx @ 947]
15 0171f2ec 60ab5f2e swlo!SwTextShell::Execute(class SfxRequest * rReq = 0x0171f49c)+0x8e0 [c:\cygwin64\home\buildslave\source\libo-core\sw\source\uibase\shells\textsh1.cxx @ 454]
16 0171f2f8 634223a4 swlo!SfxStubSwTextShellExecute(class SfxShell * pShell = 0x0a2dc278, class SfxRequest * rReq = 0x0171f49c)+0xe [c:\cygwin64\home\buildslave\r\workdir\sditarget\sw\sdi\swslots.hxx @ 2877]
17 0171f34c 63423d08 mergedlo!SfxDispatcher::Call_Impl(class SfxShell * rShell = 0x0a2dc278, class SfxSlot * rSlot = 0x0001c800, class SfxRequest * rReq = 0x0171f49c, bool bRecord = true)+0x204 [c:\cygwin64\home\buildslave\source\libo-core\sfx2\source\control\dispatch.cxx @ 376]
18 0171f380 63417af1 mergedlo!SfxDispatcher::Execute_(class SfxShell * rShell = 0x0a2dc278, class SfxSlot * rSlot = 0x60f00318, class SfxRequest * rReq = 0x0171f49c, SfxCallMode eCallMode = RECORD (0n4))+0x68 [c:\cygwin64\home\buildslave\source\libo-core\sfx2\source\control\dispatch.cxx @ 944]
19 0171f3f0 63454610 mergedlo!SfxBindings::Execute_Impl(class SfxRequest * aReq = 0x0171f49c, class SfxSlot * pSlot = 0x60f00318, class SfxShell * pShell = 0x0a2dc278)+0x2b1 [c:\cygwin64\home\buildslave\source\libo-core\sfx2\source\control\bindings.cxx @ 1172]
1a 0171f504 6345499a mergedlo!SfxDispatchController_Impl::dispatch(struct com::sun::star::util::URL * aURL = 0x0171f55c, class com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> * aArgs = 0x0171f5b8, class com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> * rListener = 0x0171f540)+0x720 [c:\cygwin64\home\buildslave\source\libo-core\sfx2\source\control\unoctitm.cxx @ 753]
1b 0171f538 631047c8 mergedlo!SfxOfficeDispatch::dispatch(struct com::sun::star::util::URL * aURL = 0x0171f55c, class com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> * aArgs = 0x0171f5b8)+0x5a [c:\cygwin64\home\buildslave\source\libo-core\sfx2\source\control\unoctitm.cxx @ 231]
1c 0171f5c8 631034de mergedlo!framework::MenuBarManager::Select(class Menu * pMenu = 0x00000001)+0x288 [c:\cygwin64\home\buildslave\source\libo-core\framework\source\uielement\menubarmanager.cxx @ 1034]
1d 0171f5d4 64158579 mergedlo!framework::MenuBarManager::LinkStubSelect(void * instance = 0x08d8f0e0, class Menu * data = 0x0a3cb1e0)+0xe [c:\cygwin64\home\buildslave\source\libo-core\framework\source\uielement\menubarmanager.cxx @ 969]
1e 0171f604 641bbf3e mergedlo!Menu::Select(void)+0x99 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\menu.cxx @ 305]
1f 0171f628 641bc486 mergedlo!ImplHandleUserEvent(struct ImplSVEvent * pSVEvent = 0x0a726cd8)+0x3e [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\winproc.cxx @ 1957]
20 0171f694 644b78aa mergedlo!ImplWindowFrameProc(class vcl::Window * _pWindow = 0x0a04cc10, SalEvent nEvent = UserEvent (0n19), void * pEvent = 0x0a726cd8)+0x3c6 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\window\winproc.cxx @ 2507]
21 0171f6f0 644b7ea0 mergedlo!SalFrameWndProc(struct HWND__ * hWnd = 0x000b05a4, unsigned int nMsg = 0x482, unsigned int wParam = 0, long lParam = 0n175271128, int * rDef = 0x0171f71c)+0x75a [c:\cygwin64\home\buildslave\source\libo-core\vcl\win\window\salframe.cxx @ 5771]
22 0171f73c 73cfafcb mergedlo!SalFrameWndProcW(struct HWND__ * hWnd = 0x000b05a4, unsigned int nMsg = 0x482, unsigned int wParam = 0, long lParam = 0n175271128)+0x60 [c:\cygwin64\home\buildslave\source\libo-core\vcl\win\window\salframe.cxx @ 5905]
23 0171f768 73cec948 user32!AddClipboardFormatListener+0x11eb
24 0171f850 73cec1c7 user32!DispatchMessageW+0xc78
25 0171f8c4 73cebce0 user32!DispatchMessageW+0x4f7
26 0171f8d0 64482144 user32!DispatchMessageW+0x10
27 0171f904 64481f9a mergedlo!ImplSalYield(bool bWait = false, bool bHandleAllCurrentEvents = false)+0x64 [c:\cygwin64\home\buildslave\source\libo-core\vcl\win\app\salinst.cxx @ 592]
28 0171f92c 643c6dd7 mergedlo!WinSalInstance::DoYield(bool bWait = false, bool bHandleAllCurrentEvents = false, unsigned long nReleased = 0)+0xca [c:\cygwin64\home\buildslave\source\libo-core\vcl\win\app\salinst.cxx @ 657]
29 0171f96c 63626939 mergedlo!Application::Execute(void)+0x177 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svapp.cxx @ 469]
2a 0171facc 643cdb7a mergedlo!desktop::Desktop::Main(void)+0xd59 [c:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\app.cxx @ 1683]
2b 0171faf4 643cdf39 mergedlo!ImplSVMain(void)+0x6a [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svmain.cxx @ 185]
2c 0171fb00 63640114 mergedlo!SVMain(void)+0x29 [c:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svmain.cxx @ 224]
2d 0171fc54 00ce101e mergedlo!soffice_main(void)+0x104 [c:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\sofficemain.cxx @ 166]
2e 0171fca8 74368724 soffice+0x101e
2f 0171fcbc 771d83c7 kernel32!BaseThreadInitThunk+0x24
30 0171fd04 771d8397 ntdll!ApiSetQueryApiSetPresence+0xd7
31 0171fd14 00000000 ntdll!ApiSetQueryApiSetPresence+0xa7

It would seem svx::SvxShowCharSetVirtualAcc::getAccessibleChild throws an IndexOutOfBoundsException:
https://github.com/LibreOffice/core/blob/libreoffice-5.3.0.3/svx/source/accessibility/charmapacc.cxx#L131
Comment 19 V Stuart Foote 2017-02-14 06:36:39 UTC 
from builds on hand, bisected the LO crash on launch of Special Character dialog down to between 2015-05-10 and 2015-05-15 so between 5.0.0.0alpha1+ and 5.0.0.0beta1

Simple STR of running NVDA and creating a new Writer document. Type anything so not a blank line, and then Insert -> Special Character to launch the dialog.

https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=2796bc31e90c87cee10d832a67b1fd9dcab6e51f..9d0c51daea67104349cac26de9839afa8baeb099

could still use a tighter bibisect
Comment 20 Commit Notification 2017-02-15 16:55:49 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b3098d239f46c8d5965754f275bc62216dcb4f4f

Related: tdf#105712 inconsistency with num of a11y children in special char

It will be available in 5.4.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 21 Caolán McNamara 2017-02-15 17:01:31 UTC 
There is a buggy inconsistency in the accessibility of that special character widget, it claims to have one child if there is no scrollbar, but if you request the accessibility context of child index 0 then it throws that its an invalid index which is nonsense. Perhaps that's is the root problem here. Hopefully someone can check in the next daily that has this problem if this helps out or not. 

Either way, its worth fixing so backports to 5-3 and 5-2 in gerrit
Comment 22 Aron Budea 2017-02-15 22:20:12 UTC Comment hidden (bibisection)
Comment 23 Aron Budea 2017-02-15 22:22:31 UTC 
I bibisected it to have this information as well, and it points to the commit referenced below. Adding Cc: to Tomaž Vajngerl.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=613ead6d876508b0da32a4511b140b7f2abdac73
author		Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2015-05-12 06:54:38 (GMT)
committer	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2015-05-12 23:36:29 (GMT)

"refactor SvxShowCharSet to use RenderContext"
Comment 24 V Stuart Foote 2017-02-16 03:06:00 UTC 
(In reply to Caolán McNamara from comment #21)
> ... Hopefully someone can check in the next daily that has this
> problem if this helps out or not. 
> 
> Either way, its worth fixing so backports to 5-3 and 5-2 in gerrit

Thanks, that seems to have fixed the crash. Can not reproduce from Insert menu, Toolbar or the Spell check button.

But curious if there is still something to adjust with the commit picked up in the bibisect.  Also, shouldn't the issue in svx in accessibility and the charmapacc also have affected Orca users?


=-testing-=
On Windows 10 Pro 64-bit en-US with
Version: 5.4.0.0.alpha0+
Build ID: 6de3688cc6bd52ce08ff8a4327e59dbbc8a5c7d4
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-15_23:33:50
Locale: en-US (en_US); Calc: CL
Comment 25 Caolán McNamara 2017-02-16 08:58:53 UTC 
Seeing as its reportedly works now I'll close this. Wrt ORCA I didn't see any similar problem there, no idea why, perhaps its just a timing thing with NVDA just requesting the child at a different point along the resize sequence than orca or the gtk ally integration catches different exceptions or something like that.
Comment 26 Commit Notification 2017-02-16 10:55:17 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2247313b0aec80306e7f67926810cf004d5b4d1d&h=libreoffice-5-2

Related: tdf#105712 inconsistency with num of a11y children in special char

It will be available in 5.2.6.

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

Affected users are encouraged to test the fix and report feedback.
Comment 27 Commit Notification 2017-02-16 10:55:25 UTC 
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ba8ac3843790226385e55bdf222de0d3aecc281d&h=libreoffice-5-3

Related: tdf#105712 inconsistency with num of a11y children in special char

It will be available in 5.3.1.

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

Affected users are encouraged to test the fix and report feedback.
Comment 28 am_dxer 2017-02-16 13:01:37 UTC 
I also confirm no more crash on either of my windows machines.
Version: 5.4.0.0.alpha0+
Build ID: 6de3688cc6bd52ce08ff8a4327e59dbbc8a5c7d4
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-15_23:33:50
Locale: en-US (en_US); Calc: group