Bug 73464 - ACCESSIBILITY: 4.2.0.3 RC3 QA Blocker -- crash when IA2 bridge is active-- pressing ENTER key creating new paragraph, or a BACKSPACE when rubbing out paragraph
Summary: ACCESSIBILITY: 4.2.0.3 RC3 QA Blocker -- crash when IA2 bridge is active-- pr...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.2.0.2 rc
Hardware: x86-64 (AMD64) Windows (All)
: highest blocker
Assignee: Not Assigned
URL:
Whiteboard: target:4.3.0 target:4.2.0
Keywords:
Depends on:
Blocks: a11y-Windows mab4.2
  Show dependency treegraph
 
Reported: 2014-01-10 08:49 UTC by V Stuart Foote
Modified: 2014-02-05 08:27 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
screen clip of soffice.bin ProcessExplorer properties (34.40 KB, image/png)
2014-01-11 19:52 UTC, V Stuart Foote
Details
clip of Process Explorer capture of soffice.bin crash with IA2 active on test build (81.64 KB, image/png)
2014-01-13 03:11 UTC, V Stuart Foote
Details
stack trace of WinDbg attached analyze -v session (25.14 KB, text/plain)
2014-01-15 15:59 UTC, V Stuart Foote
Details
dump file of crashing soffice.bin (2.66 MB, application/octet-stream)
2014-01-15 16:01 UTC, V Stuart Foote
Details
WinDbg analyze -v of soffice.bin dump file (6.37 KB, text/plain)
2014-01-15 16:04 UTC, V Stuart Foote
Details
DrMemory run against soffice.exe, and open Writer. Issues in soffice.bin but no crash (24.79 KB, text/plain)
2014-01-15 22:41 UTC, V Stuart Foote
Details
full set of DrMemory logs for soffice.bin process logged in 92195 attachment-- an IA2 enabled writer session (23.38 KB, application/zip)
2014-01-15 23:18 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2014-01-10 08:49:24 UTC
If the IA2 UAA bridge is active while any existing document or any new is being edited--Writer, Calc, Impress--pressing the ENTER key is immediately crashing the edit session and LibreOffice "stops workings" and enters a document recovery cycle on next launch.
 
Issue noted on multiple installations different workstations, Windows 7 sp1, 64-bit en-US with LibreOffice 4.2.0.2 RC2.  en-US Help pack also installed.

Version: 4.2.0.2
Build ID: cd65d6220c5694ee7012d7863bcde3455c9e3c30

IA2 enabled by selection of Tools --> Options --> Advanced "Enable experimental features"

Monitoring with AccProbe and JavaFerret32 to verify switch from JAB or IA2 support for AT is active following logoff/logon.  Issue occurs with either NVDA (2013.2) or if setting Environment variable SAL_FORCE_IACCESSIBLE2 set to "1".

This is unique to the 4.2.0.2 RC build.  Recent TB builds of 4.2.0 branch are fine.
Comment 1 V Stuart Foote 2014-01-10 09:12:55 UTC
Verified that a /A parallel install of the next TB 42 build following the tag, works without issue.

Version: 4.2.1.0.0+
Build ID: 8308f6e5f50bcdd5cd4e5511a8a3bd5c64c93e2b
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-01-08_09:46:01
Comment 2 V Stuart Foote 2014-01-10 09:47:21 UTC
Removing the 4.2.0.2 en-US Help package made no improvement.

Performing a /A administrative install of the 4.2.0.2 msi package also does not help, the <ENTER> key press continues to crash the edit session when IAccessible2 is active.
Comment 3 V Stuart Foote 2014-01-10 16:33:22 UTC
Can also consistently cause LO 4.2.0.2 to crash while editing a document with some existing text by positioning with cursor to an empty line and then pressing <BACKSPACE> to rub out a Paragraph mark.

With no AT active, and AccProbe not running to monitor AT (so IA2 AT support disabled), the same <BACKSPACE> removal of paragraph mark does not crash LO.

Attempting to isolate for stacktrace the program action, but its being elusive and the Windows application error is useless.
Comment 4 Jean-Baptiste Faure 2014-01-11 09:47:54 UTC
Hi Stuart,

You should download Windows version 4.2.0.2 again. The build you tested is broken as Christian Lohmaier said on QA mailing list.
Correct build ID is 601a398b803303d1a40a3299729531824fe0db56 (https://gerrit.libreoffice.org/gitweb?p=core.git;a=shortlog;h=refs/tags/libreoffice-4.2.0.2-buildfix1)

Best regards. JBF
Comment 5 V Stuart Foote 2014-01-11 16:41:40 UTC
(In reply to comment #4)
> Hi Stuart,
> 
> You should download Windows version 4.2.0.2 again. The build you tested is
> broken as Christian Lohmaier said on QA mailing list.
> Correct build ID is 601a398b803303d1a40a3299729531824fe0db56
> (https://gerrit.libreoffice.org/gitweb?p=core.git;a=shortlog;h=refs/tags/
> libreoffice-4.2.0.2-buildfix1)
> 
> Best regards. JBF
Jean-Baptiste,

Wish I could, but the Windows build posted to the /pre-release site remains
Version: 4.2.0.2
Build ID: cd65d6220c5694ee7012d7863bcde3455c9e3c30

Verified HASH values of all prior attempts against the build still posted to http://dev-builds.libreoffice.org/pre-releases/win/x86/ package listed as LibreOffice_4.2.0.2_Win_x86.msi  09-Jan-2014 12:00  210M
Comment 6 V Stuart Foote 2014-01-11 19:52:06 UTC
Created attachment 91877 [details]
screen clip of soffice.bin ProcessExplorer properties

Still struggling to isolate the issue; I think is is OLE32 but I'm not certain.
Attached a capture of a crashing Writer edit session following rub out of a paragraph mark.

=-=Stack Traces=-=

Here is stack trace for the hung soffice.bin process:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
ntdll.dll!RtlReportException+0x86
ntdll.dll!RtlpNtEnumerateSubKey+0x1ab9
ntdll.dll!RtlpNtEnumerateSubKey+0x1b36
ntdll.dll!RtlpNtEnumerateSubKey+0x2a2c
ntdll.dll!RtlpNtEnumerateSubKey+0x2b0c
ntdll.dll!RtlUlonglongByteSwap+0xc811
ole32.dll!CoGetComCatalog+0x4f7
OLEAUT32.dll!GetErrorInfo+0x519
OLEAUT32.dll!SysFreeString+0x4a
OLEAUT32.dll!BSTR_UserFree+0x19
RPCRT4.dll!NdrUserMarshalFree+0x37
RPCRT4.dll!NdrStubCall2+0x4a3
RPCRT4.dll!NdrStubCall2+0x38f
ole32.dll!WdtpInterfacePointer_UserUnmarshal+0x256f
ole32.dll!WdtpInterfacePointer_UserUnmarshal+0x25ff
ole32.dll!WdtpInterfacePointer_UserUnmarshal+0x2b59
ole32.dll!CoTaskMemFree+0x1b02
ole32.dll!CoTaskMemFree+0x19f7
ole32.dll!DcomChannelSetHResult+0x8ff
ole32.dll!WdtpInterfacePointer_UserUnmarshal+0x2a56
ole32.dll!WdtpInterfacePointer_UserUnmarshal+0x28ca
ole32.dll!WdtpInterfacePointer_UserUnmarshal+0x2f86
ole32.dll!DcomChannelSetHResult+0x75c
ole32.dll!DcomChannelSetHResult+0x71b
USER32.dll!gapfnScSendMessage+0x332
USER32.dll!GetThreadDesktop+0xd7
USER32.dll!CharPrevW+0x138
USER32.dll!DispatchMessageW+0xf
vcllo.dll!?IsMaximized@WorkWindow@@QBEEXZ+0x9cf0
vcllo.dll!?IsMaximized@WorkWindow@@QBEEXZ+0x9e60
vcllo.dll!?Execute@Application@@SAXXZ+0x97
vcllo.dll!?Execute@Application@@SAXXZ+0x20
vcllo.dll!??4EmbeddedFontsHelper@@QAEAAV0@ABV0@@Z+0x171
soffice.bin!main+0x51
soffice.bin!main+0x229
soffice.bin!main+0x8f5

And stack trace for the associated sal3.dll process:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
sal3.dll!rtl_cache_free+0x395
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

And stack trace for the associated MSVCR100.dll process:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
KERNELBASE.dll!WaitForSingleObject+0x12
KERNELBASE.dll!GetOverlappedResult+0x57
sal3.dll!osl_acceptPipe+0x80
KERNELBASE.dll!RaiseException+0x58
sal3.dll!osl_unloadUserProfile+0x829
MSVCR100.dll!_endthreadex+0x3a
MSVCR100.dll!_endthreadex+0xe4
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

And finally stack trace for associated ole32.dll process:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x56b
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwDelayExecution+0x15
KERNELBASE.dll!Sleep+0xf
ole32.dll!CoGetTreatAsClass+0x325e
ole32.dll!CoGetTreatAsClass+0x314b
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
Comment 7 Julien Nabet 2014-01-11 20:24:38 UTC
V Stuart Foote : this link could help to retrieve a backtrace :
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace
Comment 8 V Stuart Foote 2014-01-11 21:22:28 UTC
(In reply to comment #7)
> V Stuart Foote : this link could help to retrieve a backtrace :
> https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:
> _How_to_get_a_backtrace

Thanks Julien, but the stack trace provided is functionally equivalent and is using Windows 8.1 SDK Debugtools -- debughelp.dll, and Cloph's project symbols for the 4.2.0 build from http://dev-downloads.libreoffice.org/symstore/symbols

Only difference is using SysInternals Process Explorer or Process Monitor to follow the processes. These stack traces were following soffice.bin from Process Explorer, but if someone can pin the keystroke event down futher--great.

=-=Ref for using Symbols with Sysinternal PE or PM=-=
http://windowsexplored.com/2012/01/31/resolve-symbols-in-process-explorer-monitor-without-installing-the-debugging-tools/

http://blogs.msdn.com/b/vijaysk/archive/2009/04/02/getting-better-stack-traces-in-process-monitor-process-explorer.aspx
Comment 9 Julien Nabet 2014-01-11 21:47:51 UTC
V Stuart: I recognize I know too few about stacktraces from Windows.
Re reading it, I wondered if it could be a pb in vcl module, IsMaximized function.
But I prefer letting other give their idea.
Comment 10 Christian Lohmaier 2014-01-12 03:19:58 UTC
(In reply to comment #4)
> 
> You should download Windows version 4.2.0.2 again. The build you tested is
> broken as Christian Lohmaier said on QA mailing list.

Nope, there's a little confusion. The initial upload was not from the tag (as was apparent by not being called "4.2.0.2" - so that build was removed and windows build was redone with the initial libreoffice-4.2.0.2 tag (that is cd65d6220c5694ee7012d7863bcde3455c9e3c30 )

> Correct build ID is 601a398b803303d1a40a3299729531824fe0db56
> (https://gerrit.libreoffice.org/gitweb?p=core.git;a=shortlog;h=refs/tags/
> libreoffice-4.2.0.2-buildfix1)

This is only for the linux builds, as the buildfix only is about the package dependency problem, no code change.


Difference between Win@42 buidls and the release builds is that the release one uses --with-distro=LibreOfficeWin32 configure switch, i.e. all switches from
http://cgit.freedesktop.org/libreoffice/core/tree/distro-configs/LibreOfficeWin32.conf?h=libreoffice-4-2-0

(and additionally also --enable-symbols to create the pdbs)

I'll create a build and only mimic the options of the @42 box. That will tell whether VisualStudio 2012 vs Visual Studio 2010 is the problem...
Comment 11 Christian Lohmaier 2014-01-12 23:53:51 UTC
http://dev-builds.libreoffice.org/tmp/fdo_73464/ the build with only ia2 and none of the other feature-switches from distro-config
Comment 12 V Stuart Foote 2014-01-13 03:11:14 UTC
Created attachment 91920 [details]
clip of Process Explorer capture of soffice.bin crash with IA2 active on test build

Christian,
(In reply to comment #11)
> http://dev-builds.libreoffice.org/tmp/fdo_73464/ the build with only ia2 and
> none of the other feature-switches from distro-config

Thanks for spinning up a test build. Unfortunately, no improvement with a /A administrative install.

Attached a Process Explorer screen clip of hung soffice.bin

With these additional stack traces...

Stack trace fo soffice.bin main process 6976:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
ntdll.dll!RtlReportException+0x86
ntdll.dll!RtlpNtEnumerateSubKey+0x1ab9
ntdll.dll!RtlpNtEnumerateSubKey+0x1b36
ntdll.dll!RtlpNtEnumerateSubKey+0x2a2c
ntdll.dll!RtlpNtEnumerateSubKey+0x2b0c
ntdll.dll!RtlUlonglongByteSwap+0xc811
ole32.dll!CoGetComCatalog+0x4f7

stack trace for sal3.dll process 5196:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
sal3.dll!rtl_cache_free+0x395
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36


stack trace for ole32 process 5200:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x56b
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwDelayExecution+0x15
KERNELBASE.dll!Sleep+0xf
ole32.dll!CoGetTreatAsClass+0x325e
ole32.dll!CoGetTreatAsClass+0x314b
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36


And stack traces for the associated MSVCR100.dll process 2760:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
KERNELBASE.dll!WaitForSingleObject+0x12
KERNELBASE.dll!GetOverlappedResult+0x57
sal3.dll!osl_acceptPipe+0x80
KERNELBASE.dll!RaiseException+0x58
sal3.dll!osl_unloadUserProfile+0x829
MSVCR100.dll!_endthreadex+0x3a
MSVCR100.dll!_endthreadex+0xe4
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

and for process 3684:
=-=-=
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlIsDosDeviceName_U+0x23a27
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForMultipleObjects+0x15
kernel32.dll!WaitForMultipleObjectsEx+0x8e
kernel32.dll!WaitForMultipleObjects+0x18
MSVCR100.dll!_endthreadex+0x3a
MSVCR100.dll!_endthreadex+0xe4
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

Don't want to clutter up the BZ with additional, but if someone needs to see some other detail posted, happy to oblige.  Any ideas?
Comment 13 Michael Meeks 2014-01-13 17:32:06 UTC
Any thoughts Michael ? :-)
Comment 14 V Stuart Foote 2014-01-15 15:59:42 UTC
Created attachment 92158 [details]
stack trace of WinDbg attached analyze -v session

Trace caught using WinDbg.exe (Win 8 SDK) attached to soffice.bin process
Comment 15 V Stuart Foote 2014-01-15 16:01:30 UTC
Created attachment 92159 [details]
dump file of crashing soffice.bin
Comment 16 V Stuart Foote 2014-01-15 16:04:16 UTC
Created attachment 92160 [details]
WinDbg analyze -v of soffice.bin dump file

A WinDbg analyze -v of the soffice.bin dump file caught during the IA2 bridge crash when entering an <Enter> key.

Not much improved over the earlier traces.
Comment 17 Michael Meeks 2014-01-15 17:15:20 UTC
Stuart; the trace would be best done with the symbol server setup (or somesuch) I guess - or a build that has symbols; there is no good data there:

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for vcllo.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for sofficeapp.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for soffice.bin - 
Cannot find frame 0x9, previous scope unchanged
...

are not good signs from that perspective.

Beyond that - it looks like a heap corruption: these are exciting bugs to track on Windows. I'd recommend running it under:

http://drmemory.org/

which makes it 40x slower or worse, but should catch the problem in a helpful way - it'd be fantastic to have some output from drmemory for this specifically - and ideally with symbols.  With a drmemory trace (as with valgrind) it should point is ~directly at the real bug =)

Thanks so much for chasing though !
Comment 18 V Stuart Foote 2014-01-15 22:41:47 UTC
Created attachment 92195 [details]
DrMemory run against soffice.exe, and open Writer. Issues in soffice.bin but no crash

Use a DrMemory command line of:
"drmemory -no_count_leaks -ignore_asserts -no_check_uninitialized -- soffice.exe"

In this log, set IAccessible2 experimental feature enabled in advance in LibreOffice 4.2.0.2--launch of soffice.exe with command line above.

Open a Writer session.

But, I could not make soffice.bin crash with DrMemory running.

However, Error(s) 5 & 6, and Error(s) 7 & 8 occur in Writer session when paragraph mark is first inserted and then with cursor movement another paragraph mark is deleted.
Comment 19 V Stuart Foote 2014-01-15 23:18:15 UTC
Created attachment 92196 [details]
full set of DrMemory logs for soffice.bin process logged in 92195 attachment-- an IA2 enabled writer session

zip of full set of DrMemory logs, rather that the copy paste stderr log of attachment 92195 [details].

global.2292.log
results.txt
potential_errors.txt
suppress.txt
missing_symbols.txt

The DrMemory run seems to keep the soffice session open, resumes crashing on edit when run alone.
Comment 20 Björn Michaelsen 2014-01-17 09:40:33 UTC
(This is an automated message.)

Setting priority to highest as this is a 4.2 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 21 Niklas Johansson 2014-01-22 10:10:57 UTC
I can reproduce on Windows 8.0 with LibreOffice Version: 4.2.0.2
Build ID: cd65d6220c5694ee7012d7863bcde3455c9e3c30

I cannot reproduce with the daily build Version: 4.2.1.0.0+
Build ID: 23221e48495262d0384c9169a0d8a01db8a5dab5

Since 4.2.0.3 is to be released shortly I'll wait for that release to try again. Keeping my fingers crossed that whatever was fixed between the releases above will be available in the next release candidate as well.
Comment 22 V Stuart Foote 2014-01-23 04:20:53 UTC
On Windows 7 sp1, 64-bit with
Version: 4.2.0.3
Build ID: c63c03decdf780d8fb80823950665b782ec9ecd0

Sorry to have to report that the issues from the release build of RC2 continue with the RC3 build.

Have enabled experimental features activating IAccessible2 AT support monitoring with NVDA (2013.2).

WinDbg attached to soffice.bin process.

"receiving multiple (e64.db4): C++ EH exception - code e06d7363 (first chance)"
errors. And on a rub out of paragraph mark see this error and its stack trace 'k' result.

0:000> g
(e64.ff8): Unknown exception - code c0000374 (first chance)
(e64.ff8): Unknown exception - code c0000374 (!!! second chance !!!)
eax=00bff12c ebx=00000000 ecx=77d20b42 edx=00bfeec9 esi=00c00000 edi=65a55c1c
eip=77d7e753 esp=00bff11c ebp=00bff194 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!RtlpNtEnumerateSubKey+0x1b26:
77d7e753 eb12            jmp     ntdll!RtlpNtEnumerateSubKey+0x1b3a (77d7e767)
0:000> k
ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
00bff194 77d7f659 ntdll!RtlpNtEnumerateSubKey+0x1b26
00bff1a4 77d7f739 ntdll!RtlpNtEnumerateSubKey+0x2a2c
00bff1d8 77d39cb1 ntdll!RtlpNtEnumerateSubKey+0x2b0c
00bff200 64e4959c ntdll!RtlUlonglongByteSwap+0xc811
00bff224 772e625c AcXtrnal+0x959c
00bff238 770b443a ole32!CoGetComCatalog+0x4f7
00bff25c 770b3ea3 OLEAUT32!GetErrorInfo+0x519
00bff278 770b7803 OLEAUT32!SysFreeString+0x4a
00bff288 76d87af6 OLEAUT32!BSTR_UserFree+0x19
00bff2c0 76e0083e RPCRT4!NdrUserMarshalFree+0x37
00bff2e4 76e0072a RPCRT4!NdrStubCall2+0x4a3
00bff6f0 773dd7e6 RPCRT4!NdrStubCall2+0x38f
00bff738 773dd876 ole32!WdtpInterfacePointer_UserUnmarshal+0x256f
00bff780 773dddd0 ole32!WdtpInterfacePointer_UserUnmarshal+0x25ff
00bff7cc 772f8a43 ole32!WdtpInterfacePointer_UserUnmarshal+0x2b59
00bff8a8 772f8938 ole32!CoTaskMemFree+0x1b02
00bff8c4 772f950a ole32!CoTaskMemFree+0x19f7
00bff8f0 773ddccd ole32!DcomChannelSetHResult+0x8ff
00bff924 773ddb41 ole32!WdtpInterfacePointer_UserUnmarshal+0x2a56
00bffa04 773de1fd ole32!WdtpInterfacePointer_UserUnmarshal+0x28ca
00bffa2c 772f9367 ole32!WdtpInterfacePointer_UserUnmarshal+0x2f86
00bffa40 772f9326 ole32!DcomChannelSetHResult+0x75c
00bffa84 76e862fa ole32!DcomChannelSetHResult+0x71b
00bffab0 76e86d3a USER32!gapfnScSendMessage+0x332
00bffb28 76e877c4 USER32!GetThreadDesktop+0xd7
00bffb88 76e8788a USER32!CharPrevW+0x138
00bffb98 65423a00 USER32!DispatchMessageW+0xf
00bffbd4 65423b70 vcllo!WorkWindow::IsMaximized+0x9cf0
00bffbf8 650c8127 vcllo!WorkWindow::IsMaximized+0x9e60
00bffc10 650c80b0 vcllo!Application::Execute+0x97
00bffd8c 650d2b21 vcllo!Application::Execute+0x20
00bffdb4 70e3a80f vcllo!EmbeddedFontsHelper::operator=+0x171
00bffe14 01251051 sofficeapp!soffice_main+0xbf
00bffeb0 771a336a soffice!main+0x51
00bffebc 77ce9f72 kernel32!BaseThreadInitThunk+0x12
00bffefc 77ce9f45 ntdll!RtlInitializeExceptionChain+0x63
00bfff14 00000000 ntdll!RtlInitializeExceptionChain+0x36
Comment 23 Niklas Johansson 2014-01-23 09:40:52 UTC
The behavior changed a bit for me, now I need to add a page break (Ctrl + Enter) and then press backspace to trigger the crash. Verified that no crash is triggered in the 4.2.1+ build.
Comment 24 Michael Meeks 2014-01-24 16:34:30 UTC
I'm running a build from the 4-2 branch and can't reproduce the problem at all - presumably I need to build -4-2-0 now ...
Comment 25 V Stuart Foote 2014-01-24 19:10:27 UTC
@Michael,
(In reply to comment #24)
> I'm running a build from the 4-2 branch and can't reproduce the problem at
> all - presumably I need to build -4-2-0 now ...

I have ONLY experienced the issue with the two LO Production releases built on Christian's release build system.

Either of these build trees:
http://downloadarchive.documentfoundation.org/libreoffice/old/4.2.0.2/win/x86/
http://downloadarchive.documentfoundation.org/libreoffice/old/4.2.0.3/win/x86/

The TB 42 builds have remained clear of the issue, and I have not heard from anyone who rolls their Windows builds own having the issue.

I don't know, but couldn't it be one of these:

1) the build with debug is enabled (no problem on TB 39 builds of master), or
2) it is a MSVC 2010 based build, or
3) something in the OLE32 and OLEAUT32 support for the release build config?
Comment 26 Michael Meeks 2014-01-24 20:29:16 UTC
This is pretty depressing - I built 4-2-0 here from "Don't crash on unstarted table" incrementally on top of 4-2 and I can't reproduce the problem at all.
Works perfectly for me. NVDA is reading nicely, showing selections etc. etc.

I'm using Visual Studio Professional 2012. I'll do a build from clean this time with the release configuration.

Christian - can you confirm the configuration you're building with ? is it only --with-distro=LibreOfficeWin32 ?

Of course - it could be related to on-line help or somesuch; a11y does touch some funny code-paths, and I never build with that ...

Thanks ! =)
Comment 27 V Stuart Foote 2014-01-26 19:09:50 UTC
So here is an interesting twist.  The TB's have been down, but noticed Chrisitian's TB 47 build of master was posted. So downloaded it and the en-US help and did an /A administrative install.

On Windows 7 sp1, 64-bit with NVDA 2013.2 running for AT

Version: 4.3.0.0.alpha0+
Build ID: 04c3d13ed942e6fc9feb78535701d48e5034d9e2
TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-01-26_00:10:53

Runs without issue with out AT active. But as soon as I activate AT and relaunch, I get a crash on activity to launch a module -- Writer in this case

Attach soffice.bin process to WinDbg, and get a series of first chance exceptions.  Symbols are a residual from TB 39 or 4.2.0.3, but some hits.
Seem to all be MSVCR100!_CxxThrowException

Have to navigate through a couple of dozen first chance exceptions before I can get the debugger to run on the writer session. Even then doesn't seem to be a specific action that will crash the writer session. Don't know if I'm cycling from WinDbg for long enough.

Point is, that the issue is no longer confined to the 4.2.0.3 RC, but is also appearing on Christian's TB 47 system build.
Comment 28 Michael Meeks 2014-01-27 10:17:53 UTC
Stuart - great data point - thanks so much for that; I'll give up trying to reproduce with 4-2-0 - I did a release build locally with VS 2012 - and can't reproduce the problem despite having the lang-packs and all that good stuff =)

I strongly suspect this is an MSVC 2010 bug - almost certainly related to Link Time Optimisation, which we should disable by default for now for 4-2-0 I think ...
Comment 29 Christian Lohmaier 2014-01-27 10:34:48 UTC
running a build right now with the --disable-lto switch
(the @47 tinderbox uses the same setup as for the release builds - so no surprise it is also affected, the other windows tinderboxes however use newer compiler)
Comment 30 Michael Meeks 2014-01-27 12:12:39 UTC
Compiler conspiracy theories aside (perhaps they provoke some race or other) ;-) I have a good hard crash in UAccCom.dll here where: CMAccessible::get_attributes() is called on an object where m_isDestroy is true and m_xAccessible is cleared / empty.

Just pushed a patch that adds a number of checks vs. that sort of thing ...
Comment 31 Commit Notification 2014-01-27 12:16:45 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

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

fdo#73464 - guard against NULL / unset m_xAccessible.



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 32 Commit Notification 2014-01-27 12:25:23 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

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

fdo#73464 - guard against NULL / unset m_xAccessible.


It will be available in LibreOffice 4.2.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 33 Commit Notification 2014-01-27 12:26:43 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-2-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=37bb1d0d8032eb859322d7d3c60f8799e48250a0&h=libreoffice-4-2-0

fdo#73464 - guard against NULL / unset m_xAccessible.


It will be available already in LibreOffice 4.2.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 34 Christian Lohmaier 2014-01-27 12:43:47 UTC
http://dev-builds.libreoffice.org/daily/master/Win-x86@47-TDF/2014-01-27_10.20.52/  ← build with the --disable-lto switch
Comment 35 Michael Meeks 2014-01-27 14:27:41 UTC
No difference with the non-LTO build - well - it still crashes; but of course there could have been two bugs - I suggest we disable LTO here anyway just in case (we can't explain a difference otherwise).

Beyond that the crash I get looks just like the thing I fixed above.
Comment 36 Commit Notification 2014-01-27 14:45:39 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-2-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=37376041d4c30588fc577c20ec91a14e819d439a&h=libreoffice-4-2-0

Disable LTO for now - suspected cause of fdo#73464.


It will be available already in LibreOffice 4.2.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 37 V Stuart Foote 2014-01-27 15:52:26 UTC
@Michael
(In reply to comment #30)
> Compiler conspiracy theories aside (perhaps they provoke some race or other)
> ;-) I have a good hard crash in UAccCom.dll here where:
> CMAccessible::get_attributes() is called on an object where m_isDestroy is
> true and m_xAccessible is cleared / empty.
> 
> Just pushed a patch that adds a number of checks vs. that sort of thing ...

Cool! Will have a go on next round of TB builds. 

Meanwhile, noticed over on the AOO side that Mick Curran (co-lead on the NVDA project) reached the same conclusion and contributed a patch to MAccessible.cpp that Steve Yin has rolled in as rev 1561587 (http://svn.apache.org/viewvc?view=revision&revision=1561587 ). It looks to be touching some of the same issues and might be worth a review.

Stuart
Comment 38 Commit Notification 2014-01-27 18:02:14 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

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

fdo#73464 - get relation BSTR allocation right.



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 39 Commit Notification 2014-01-27 18:04:35 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=514c1ed971dfb9978848ba667598b336ad2943d2&h=libreoffice-4-2

fdo#73464 - get relation BSTR allocation right.


It will be available in LibreOffice 4.2.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 40 Michael Meeks 2014-01-27 18:06:46 UTC
My thesis is that this BSTR allocation mess-up is something that the C run-times for 2010 and 2012 differ on - the latter being more tolerant of people doing stupid stuff with BSTRs (perhaps), and that's why we were getting the crash only with a 2010 build.
Comment 41 Commit Notification 2014-01-27 18:11:07 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-2-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=efed46563307075fb19bac3177e9d3243eb39ef5&h=libreoffice-4-2-0

fdo#73464 - get relation BSTR allocation right.


It will be available already in LibreOffice 4.2.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 42 Commit Notification 2014-01-27 18:18:45 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=649eba4229cc0a22bdd8160cf4d19470aae9300c&h=libreoffice-4-2

Disable LTO for now - suspected cause of fdo#73464.


It will be available in LibreOffice 4.2.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 43 Michael Meeks 2014-01-27 21:32:28 UTC
Was the BSTR allocation (and the other crash) all along; we can prolly re-enable LTO for 4.2.1 on the -4-2 branch in a bit: I imagine it helps.

Glad to see this working smoothly (for me at least) in the Win-x86@47 TDF builds as of 2014-01-27_19.12.00

Whoot =)
Comment 44 V Stuart Foote 2014-01-28 00:35:05 UTC
Downloaded Christian's TB 47 build of Master with today's patches, no problems with it now on a /A administrative install on Windows 7 sp1, 64-bit and NVDA 2013.2 and AccProbe active for AT.

Version: 4.3.0.0.alpha0+
Build ID: 7f2a2d2b05e64ee425f95d189ed6ef32d8895ab9
TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-01-27_19:12:00

Actions that would crash prior builds are running without issue. Assuming patches all make it down for the 4.2.0 branch for next RC build, concur in calling this Resolved Fixed.  Thanks to all.
Comment 45 V Stuart Foote 2014-01-28 19:17:27 UTC
Verified fixed on today's LibreOffice 4.2.0.4 RC4 build!

Version: 4.2.0.4
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71

Full custom* installation on Windows 7 sp1, 64-bit with NVDA (2013.2) active and using the 'Enable AT support' check box during install. Then activating 'Enable experimental features' during first launch.  

*Custom -- deselect additional dictionaries, quickstarter, automatic updates and the non-linear problem solver, and include language support for english only.
Comment 46 Commit Notification 2014-02-05 08:27:50 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=003da68ee630539a83316165afc5ff11c37ccb00&h=libreoffice-4-2

Revert "Disable LTO for now - suspected cause of fdo#73464."


It will be available in LibreOffice 4.2.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.