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.
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
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.
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.
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
(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
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
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
(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
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.
(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...
http://dev-builds.libreoffice.org/tmp/fdo_73464/ the build with only ia2 and none of the other feature-switches from distro-config
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?
Any thoughts Michael ? :-)
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
Created attachment 92159 [details] dump file of crashing soffice.bin
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.
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 !
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.
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.
(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.
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.
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
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.
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 ...
@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?
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 ! =)
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.
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 ...
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)
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 ...
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.
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.
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.
http://dev-builds.libreoffice.org/daily/master/Win-x86@47-TDF/2014-01-27_10.20.52/ ← build with the --disable-lto switch
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.
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.
@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
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.
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.
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.
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.
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.
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 =)
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.
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.
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.