On Windows 8.1 64-bit en-US, nVidia Quadro K2000 GPU with Version: 5.0.0.0.beta3 (x64) Build ID: 96345c15d8ab19c49014f055fe41ba8e1f421e5c Locale: en-US (en_US) also on Windows 7 sp1 64-bit en-US, nVidia GTX260 Have had problems with 64-bit LO 5.0.0beta1, and now 5.0.0beta3 where creating a new Writer document or opening an existing writer document immediately crashes LO--but leaves soffice.bin and soffice.exe running. No affect setting OpenGL, and other components do not seem to be affected. Just Writer. Mid-May TB42 64-bit builds not similarly affected on same systems.
@Cloph, @Qubit, * Will try to get a BT, stack dump, but is there a source of symbols that will make sense to 64-bit WinDbg for these 64-bit builds?
Seems a bit much, but guess this is highest / blocker per https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
I can confirm the crash on Windows 7 that after opening a document it crashes and then shows the 'LibreOffice Document Recovery' dialog due to the crash and that it files worked on will be saved and auto recovered. Currently running WinDbg and will post the result once its finished. @Stuart: Full instruction on windbg is available here (i rewrote it with pictures :D) - https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
Created attachment 116472 [details] windbg backtrace of 500b3
(In reply to V Stuart Foote from comment #0) > > Mid-May TB42 64-bit builds not similarly affected on same systems. Stuart: What's the latest good build/commit that's working for you? I don't think we're currently building a Win64bit bibisect repo, but that might come in handy...
(In reply to Robinson Tryon (qubit) from comment #5) > (In reply to V Stuart Foote from comment #0) > > > > Mid-May TB42 64-bit builds not similarly affected on same systems. > > Stuart: What's the latest good build/commit that's working for you? I don't > think we're currently building a Win64bit bibisect repo, but that might come > in handy... Last I had on the 8.1 system that was OK from Thorsten's TB42 is Version: 5.0.0.0.alpha0+ (x64) Build ID: add7eeb7dbd0eefa0c5ae5430490864079add801 TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-17_02:28:38 Locale: en_US I have to see what I have on the Windows 7 sp1 system this evening--may not be into May as I thought, but those were the last 64-bit Windows builds I'd been able to run as Cloph's TDF build have all had issues, and no other 64-bit Windows TB to work against.
Created attachment 116476 [details] another WinDbg-64 backtrace of 500b3, same break point seems to hang at the same location as for Jay
Created attachment 116478 [details] WinDbg-64 backtrace of a 500b1 Writer launch (In reply to V Stuart Foote from comment #6) > > I have to see what I have on the Windows 7 sp1 system this evening--may not > be into May as I thought, but those were the last 64-bit Windows builds I'd > been able to run as Cloph's TDF build have all had issues, and no other > 64-bit Windows TB to work against. So, on Windows 7 sp1, 64-bit en-US the last build I had from Thorsten's TB42 was from 2015-05-15 Version: 5.0.0.0.alpha1+ (x64) Build ID: 9d0c51daea67104349cac26de9839afa8baeb099 TinderBox: Win-x86_64@42, Branch:master, Time: 2015-05-15_23:59:35 Locale: en-US (en_US) followed by Cloph/Qubit's TDF build of 5.0.0beta1 on 2015-05-21, which had issues Version: 5.0.0.0.beta1 (x64) Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3 Locale: en-US (en_US) I've attached a WinDbg-64 backtrace of failures there that also triggers with launch of Writer, but ends at a different point.
So - hanging in the python grammar checker ? I wonder if Laszlo has an idea. This affects only our new platform - x86_64 right ?
*** Bug 91693 has been marked as a duplicate of this bug. ***
(In reply to Michael Meeks from comment #9) > ... > This affects only our new platform - x86_64 right ? Yes, believe so, just x86_64 Windows builds.
I'm experiencing immediate Writer crash too. Win10_64-bit: Build 10130 LibreOffice Version: 5.0.0.0.beta3 (x64) Also see https://bugs.documentfoundation.org//show_bug.cgi?id=92046, perhaps as a duplicate.
I can confirm this behavior. I have the same issue with LO5 x64 builds since the LO 5 Alpha. Immediate crash. Open GL / Graphics / JRE settings make no difference. Writer cannot be used. Reported - Bug 92046
*** Bug 92046 has been marked as a duplicate of this bug. ***
Created attachment 116504 [details] WinDbg 64 Trace - Writer Fail - From Bug92014
I tested the same 32-bit windows build as the 64-bit build and no crash.
*** Bug 91580 has been marked as a duplicate of this bug. ***
as workaround, disable the automatic spell checking.
Starting Writer with a document where the locale has no grammar checker (i.e. French), it’s OK. When you switch the language style to English, LO crashes.
good news: not reproducible anymore in current build of both master as well as libreoffice-5-0 In other words: While I can reproduce with beta3, I can no longer with code that will end up as rc1 - so I assume it was fixed in the meantime along with another change.
I cannot reproduce with my Windows --enable-64-bit --enable-dbgutil master build from last night either. (But also couldn't reproduce in the past, as I had failed to configure --with-myspell-dicts in the past, so had had no spell checking dictionaries to begin with.)
Bug can still be reproduced in LO 5.0.0.1 win x64 build (currently on pre-release server - jun 20). As Christian pointed out, switching off the spell-checker does indeed provide a workaround that enables writer to run. I guess this means that whatever had solved the problem in master hasn't made it to the RC build. :(
As a follow up on Christian's workaround, only the 'Lightproof module' and 'check grammar while typing' option need to be turned off. The immediate crash will only reproduce with the realtime 'lightproof checker' enabled and the 'check while typing option' selected. With the lightproof module available and realtime switched off, a manual grammar check (f7) causes the crash. With lightproof off and realtime grammar off, auto and manual Spell checking functions without any problems and the hyphenation / thesaurus behave as expected. In my case, System language / dictionaries and documents being opened are all in English.
This should be fixed now with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa6670764b49a37a82641ae8d9fe77683b820190> "MSVC 64-bit: In queryInterface optimization, copy hidden ret val addr" towards LibreOffice 5.0. (Same underlying problem as bug 91988.)
(In reply to Christian Lohmaier from comment #20) > good news: not reproducible anymore in current build of both master as well > as libreoffice-5-0 The underlying bug was that a certain function should return in RAX a specific value that is already known to the caller, but instead returned garbage in RAX. Whether the caller wants to actually make use of that value returned in RAX (which it does not really need, as it already knows the value) may depend on details like --enable-debug configuration etc. That might explain that some builds exhibited actual problems while others didn't.
Wow - great fix Stephan =) I'm surprised our unit tests didn't pick it up though.
(In reply to Michael Meeks from comment #26) > I'm surprised our unit tests didn't pick it up though. I was surprised too, but also note comment 25.
Confirm resolved in Version: 5.0.0.3 (x64) Build ID: f79b5ba13f5e6cbad23f8038060e556217e66632 Locale: en-GB (en_GB)