I have tried several recent alpha/master versions of LO6 on macOS (on 10.13) and LO has problems starting; if it starts, opening a new document it closes unexpectedly, then upon restart it tries to recover broken document, and has problems finishing that by freezing in the last step of the recovery (confirming the finishing of the recovery process). As such it is unusable and this is a major, critical issue that needs to be addressed ASAP.
I tried with same "success" the following versions: 2017-09-27_02.00.53 2017-10-07_07.38.17 2017-10-08_02.51.19
Please someone confirm.
No repro with Version: 6.0.0.0.alpha0+ Build ID: 4d94541a7b88b76d856e30dba7f8a3de48260eda CPU threads: 4; OS: Mac OS X 10.13; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-10-08_02:51:19 Locale: fr-FR (fr_FR.UTF-8); Calc: group
I also can't reproduce any of the systematic crashing behaviour with my own daily build... Version: 6.0.0.0.alpha0+ Build ID: 0cb424fec7389801578085b618c5ad68a98f4637 CPU threads: 4; OS: Mac OS X 10.13; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group
Clearly, there is some information which we are missing here: - hardware ? Mac-mini (end-2014) 2,6 GHz Intel Core i5 8 Go 1600 MHz DDR3 Intel Iris 1536 Mo - monitor : CHHWJT (Chinese TV) 30,5 pouces (1920 x 1080) - Java versions ? Java9 and Java8 - user profile ? - I use a fresh profile for my own dev builds, and the daily I downloaded uses my existing LODev profile - lang-packs ? - I didn't install the daily langpack, and my own master build uses the default en-US
@Miles : outside of a possible hardware problem, is it any document that causes the crash, or particular documents ?
Note that I took the daily build from the MacOSX-x86_64@49-TDF buildbot
First thought: bug 103690
No repro either on my: MBPro 15" (end-2013) OSX 10.12.6 Retina 2.6 Ghz Intel Core i7 16Gb 1600 Mhz DDR3 Dual-graphics NVidia GeForce GT750M 2048Mb / Intel Iris Pro 1536Mb
Who can I send the crash report to? I don't want to publish it here.
I checked, thread 9 crashed, it seems connected to JVM, it doesn't matter if there is a new profile (without Java settings) or an existing one (with Java set up). So maybe this makes sense to someone: Thread 9 Crashed: 0 libsystem_kernel.dylib 0x00007fff54fe5fce __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff55123150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff54f4232a abort + 127 3 libuno_sal.dylib.3 0x000000010ae84be9 (anonymous namespace)::callSystemHandler(int, __siginfo*, void*) + 185 4 libuno_sal.dylib.3 0x000000010ae84962 (anonymous namespace)::signalHandlerFunction(int, __siginfo*, void*) + 162 5 libjvm.dylib 0x000000014acb44b7 os::Bsd::chained_handler(int, __siginfo*, void*) + 181 6 libjvm.dylib 0x000000014acb8431 JVM_handle_bsd_signal + 146 7 libjvm.dylib 0x000000014acb4a6f signalHandler(int, __siginfo*, void*) + 47 8 libsystem_platform.dylib 0x00007fff55116f5a _sigtramp + 26 9 ??? 000000000000000000 0 + 0 10 libjava_uno.dylib 0x00000001610fc36b UNO_proxy_free + 91 11 libuno_cppu.dylib.3 0x000000010b27b843 (anonymous namespace)::s_stub_defenv_revokeInterface(__va_list_tag (*) [1]) + 595 12 libuno_cppu.dylib.3 0x000000010b276a9e s_environment_invoke_v(_uno_Environment*, _uno_Environment*, void (*)(__va_list_tag (*) [1]), __va_list_tag (*) [1]) + 174 13 libuno_cppu.dylib.3 0x000000010b2769d9 uno_Environment_invoke_v + 41 14 libuno_cppu.dylib.3 0x000000010b276b5d uno_Environment_invoke + 141 15 libjava_uno.dylib 0x00000001610fc4c9 UNO_proxy_release + 9 16 libgcc3_uno.dylib 0x000000011771c155 bridges::cpp_uno::shared::freeCppInterfaceProxy(_uno_ExtEnvironment*, void*) + 149 17 libuno_cppu.dylib.3 0x000000010b27b843 (anonymous namespace)::s_stub_defenv_revokeInterface(__va_list_tag (*) [1]) + 595 18 libuno_cppu.dylib.3 0x000000010b276a9e s_environment_invoke_v(_uno_Environment*, _uno_Environment*, void (*)(__va_list_tag (*) [1]), __va_list_tag (*) [1]) + 174 19 libuno_cppu.dylib.3 0x000000010b2769d9 uno_Environment_invoke_v + 41 20 libuno_cppu.dylib.3 0x000000010b276b5d uno_Environment_invoke + 141 21 libgcc3_uno.dylib 0x000000011771c74d bridges::cpp_uno::shared::CppInterfaceProxy::releaseProxy() + 301 22 libgcc3_uno.dylib 0x0000000117713f5f cpp_vtable_call + 447 23 libgcc3_uno.dylib 0x0000000117713d56 privateSnippetExecutor + 118 24 liblnglo.dylib 0x0000000111b721c5 com::sun::star::uno::Reference<com::sun::star::linguistic2::XProofreader>::~Reference() + 21 25 liblnglo.dylib 0x0000000111b6f372 std::__1::pair<rtl::OUString const, com::sun::star::uno::Reference<com::sun::star::linguistic2::XProofreader> >::~pair() + 18 26 liblnglo.dylib 0x0000000111b6f332 std::__1::__tree<std::__1::__value_type<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::linguistic2::XProofreader> >, std::__1::__map_value_compare<rtl::OUString, std::__1::__value_type<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::linguistic2::XProofreader> >, std::__1::less<rtl::OUString>, true>, std::__1::allocator<std::__1::__value_type<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::linguistic2::XProofreader> > > >::destroy(std::__1::__tree_node<std::__1::__value_type<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::linguistic2::XProofreader> >, void*>*) + 50 27 liblnglo.dylib 0x0000000111b6e29e GrammarCheckingIterator::dispose() + 270 28 libswlo.dylib 0x0000000162224437 (anonymous namespace)::doDispose(com::sun::star::uno::Reference<com::sun::star::linguistic2::XProofreadingIterator> const&) + 87 29 libswlo.dylib 0x00000001622244de sw::proofreadingiterator::dispose() + 94 30 libswlo.dylib 0x0000000162221d09 FinitCore() + 25 31 libswlo.dylib 0x000000016281a35e SwDLL::~SwDLL() + 110 32 libswlo.dylib 0x000000016281a77b comphelper::unique_disposing_ptr<SwDLL>::reset(SwDLL*) + 27 33 libswlo.dylib 0x000000016281a58b comphelper::unique_disposing_solar_mutex_reset_ptr<SwDLL>::reset(SwDLL*) + 59 34 libswlo.dylib 0x000000016281b175 comphelper::unique_disposing_solar_mutex_reset_ptr<SwDLL>::~unique_disposing_solar_mutex_reset_ptr() + 53 35 libsystem_c.dylib 0x00007fff54f43069 __cxa_finalize_ranges + 351 36 libsystem_c.dylib 0x00007fff54f4337a exit + 55 37 libjvm.dylib 0x000000014ab1d26a vm_direct_exit(int) + 28 38 libjvm.dylib 0x000000014ade200d VM_Operation::evaluate() + 79 39 libjvm.dylib 0x000000014ade0677 VMThread::evaluate_operation(VM_Operation*) + 223 40 libjvm.dylib 0x000000014ade0ac4 VMThread::loop() + 808 41 libjvm.dylib 0x000000014ade03e3 VMThread::run() + 121 42 libjvm.dylib 0x000000014acb742e java_start(Thread*) + 246 43 libsystem_pthread.dylib 0x00007fff551206c1 _pthread_body + 340 44 libsystem_pthread.dylib 0x00007fff5512056d _pthread_start + 377 45 libsystem_pthread.dylib 0x00007fff5511fc5d thread_start + 13
It seems to be connected to language grammarchecking/spellchecking code/functionality ... If I disable the grammar checking and spell-checking, it still crashes, but at least the main window sometimes opens ...
(In reply to Martin Srebotnjak from comment #12) > It seems to be connected to language grammarchecking/spellchecking > code/functionality ... If I disable the grammar checking and spell-checking, > it still crashes, but at least the main window sometimes opens ... So, how is this grammar/spell checking invoked ? Is it due to an extension ? Which version of JDK are you using within LO ?
No, this is a clean install of master, no user profile, with default en-US spell-dictionary installed and built-in en-US grammar checking. It crashes before a new document can be opened, and if you succeed opening a new document, it crashes and all next start-ups it crashes while restoring that newly created (empty) document ... It is not connected to any certain document.
Could this be in any way connected to this (update of hunspell): https://gerrit.libreoffice.org/#/c/42555/
Why would Java be responsible for this? A fresh install in a clean profile would mean: - no extension for grammar-checking is installed (only the built-in grammar checking) - no Java environment is selected in Java settings of LO
(In reply to Martin Srebotnjak from comment #16) > Why would Java be responsible for this? > A fresh install in a clean profile would mean: > - no extension for grammar-checking is installed (only the built-in grammar > checking) > - no Java environment is selected in Java settings of LO Because in your comment 11, you pointed to a JVM problem in your backtrace ?
Maybe the spell-checking/built-in grammar checking uses or at least touches JVM at the start of LO?
Even with LanguageTool extension uninstalled (or disabled), even with Java disabled (!), the LO60alpha keeps crashing, sometimes at start, sometimes during work (if I get past the startup). For alpha build I cannot see the error/crash report in the macOS console, so this is even stranger...
Alas, it finally "officially" crashed, so here is the log: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [0] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation 0x00007fff50f4a236 getAtomTarget + 102 1 com.apple.CoreFoundation 0x00007fff50e2736c ___forwarding___ + 1036 2 com.apple.CoreFoundation 0x00007fff50e26ed8 _CF_forwarding_prep_0 + 120 3 libvcllo.dylib 0x000000011179a349 AquaSalGraphics::DrawTextLayout(CommonSalLayout const&) + 89 4 libvcllo.dylib 0x00000001115cae4f OutputDevice::ImplDrawTextDirect(SalLayout&, bool) + 271 5 libvcllo.dylib 0x00000001115cd003 OutputDevice::DrawText(Point const&, rtl::OUString const&, int, int, std::__1::vector<tools::Rectangle, std::__1::allocator<tools::Rectangle> >*, rtl::OUString*, SalLayout*) + 1299 6 libvcllo.dylib 0x00000001114e179f StatusBar::ImplDrawItem(OutputDevice&, bool, unsigned short) + 799 7 libvcllo.dylib 0x00000001114e2a33 StatusBar::Paint(OutputDevice&, tools::Rectangle const&) + 387 8 libvcllo.dylib 0x000000011143b5b6 vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) + 582 9 libvcllo.dylib 0x000000011143b19b PaintHelper::~PaintHelper() + 219 10 libvcllo.dylib 0x000000011143b662 vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) + 754 11 libvcllo.dylib 0x000000011143c85e vcl::Window::Update() + 670 12 libswlo.dylib 0x000000015080ec64 SwView::SetVisArea(tools::Rectangle const&, bool) + 468 13 libswlo.dylib 0x0000000150810ee8 SwView::CalcVisArea(Size const&) + 440 14 libswlo.dylib 0x000000015081221f SwView::OuterResizePixel(Point const&, Size const&) + 1007 15 libsfxlo.dylib 0x000000010ef4edac SfxViewFrame::DoAdjustPosSizePixel(SfxViewShell*, Point const&, Size const&, bool) + 92 16 libsfxlo.dylib 0x000000010ef520a0 SfxViewFrame::Resize(bool) + 224 17 libvcllo.dylib 0x000000011148ebea vcl::Window::ImplCallResize() + 106 18 libvcllo.dylib 0x00000001115104e6 vcl::Window::ImplPosSizeWindow(long, long, long, long, PosSizeFlags) + 2310 19 libvcllo.dylib 0x000000011151426a vcl::Window::setPosSizePixel(long, long, long, long, PosSizeFlags) + 394 20 libsfxlo.dylib 0x000000010ef2f59c SfxFrame::SetToolSpaceBorderPixel_Impl(SvBorder const&) + 268 21 libsfxlo.dylib 0x000000010ed3de77 SfxWorkWindow::ArrangeChildren_Impl(bool) + 263 22 libsfxlo.dylib 0x000000010ef2fb85 SfxFrame::Resize() + 533 23 libvcllo.dylib 0x000000011148ebea vcl::Window::ImplCallResize() + 106 24 libvcllo.dylib 0x00000001115104e6 vcl::Window::ImplPosSizeWindow(long, long, long, long, PosSizeFlags) + 2310 25 libvcllo.dylib 0x0000000111510414 vcl::Window::ImplPosSizeWindow(long, long, long, long, PosSizeFlags) + 2100 26 libvcllo.dylib 0x000000011151426a vcl::Window::setPosSizePixel(long, long, long, long, PosSizeFlags) + 394 27 libtklo.dylib 0x0000000110ca7fd0 VCLXWindow::setPosSize(int, int, int, int, short) + 304 28 libfwklo.dylib 0x000000014b6d700f framework::DockingAreaDefaultAcceptor::setDockingAreaSpace(com::sun::star::awt::Rectangle const&) + 431 29 libfwklo.dylib 0x000000014b700e6a framework::LayoutManager::implts_doLayout(bool, bool) + 1306 30 libfwklo.dylib 0x000000014b70509d framework::LayoutManager::AsyncLayoutHdl(Timer*) + 93 31 libfwklo.dylib 0x000000014b704b6b framework::LayoutManager::windowResized(com::sun::star::awt::WindowEvent const&) + 139 32 libtklo.dylib 0x0000000110d8dbda WindowListenerMultiplexer::windowResized(com::sun::star::awt::WindowEvent const&) + 154 33 libtklo.dylib 0x0000000110ca692b VCLXWindow::ProcessWindowEvent(VclWindowEvent const&) + 3931 34 libvcllo.dylib 0x000000011148d9f0 vcl::Window::CallEventListeners(VclEventId, void*) + 320 35 libvcllo.dylib 0x00000001115104e6 vcl::Window::ImplPosSizeWindow(long, long, long, long, PosSizeFlags) + 2310 36 libvcllo.dylib 0x00000001114486c0 ImplBorderWindow::Resize() + 688 37 libvcllo.dylib 0x00000001114e8fcd SystemWindow::SetNotebookBar(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) + 93 38 libsfxlo.dylib 0x000000010eee516e sfx2::SfxNotebookBar::StateMethod(SystemWindow*, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, rtl::OUString const&) + 782 39 libswlo.dylib 0x000000015067fd70 SwDocShell::GetState(SfxItemSet&) + 480 40 libsfxlo.dylib 0x000000010ed7d018 SfxShell::GetSlotState(unsigned short, SfxInterface const*, SfxItemSet*) + 232 41 libsfxlo.dylib 0x000000010ed60555 SfxDispatcher::QueryState(unsigned short, SfxPoolItem const*&) + 101 42 libsfxlo.dylib 0x000000010ed5e312 SfxDispatcher::Update_Impl(bool) + 1058 43 libsfxlo.dylib 0x000000010ecc78f4 SfxApplication::SetViewFrame_Impl(SfxViewFrame*) + 612 44 libsfxlo.dylib 0x000000010ef5076a SfxViewFrame::MakeActive_Impl(bool) + 266 45 libsfxlo.dylib 0x000000010ef41df9 SfxBaseController::ConnectSfxFrame_Impl(SfxBaseController::ConnectSfxFrame) + 1193 46 libsfxlo.dylib 0x000000010ef417f7 SfxBaseController::attachFrame(com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) + 327 47 libsfxlo.dylib 0x000000010ef3453f (anonymous namespace)::SfxFrameLoader_Impl::impl_createDocumentView(com::sun::star::uno::Reference<com::sun::star::frame::XModel2> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, comphelper::NamedValueCollection const&, rtl::OUString const&) + 383 48 libsfxlo.dylib 0x000000010ef32938 (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) + 1352 49 libfwklo.dylib 0x000000014b71fa10 framework::LoadEnv::impl_loadContent() + 1344 50 libfwklo.dylib 0x000000014b71cf96 framework::LoadEnv::startLoading() + 166 51 libfwklo.dylib 0x000000014b6d445d framework::LoadDispatcher::impl_dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) + 525 52 libfwklo.dylib 0x000000014b6d477a framework::LoadDispatcher::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 74 53 libsfxlo.dylib 0x000000010ed7760d sfx2::RecentDocsView::ExecuteHdl_Impl(sfx2::RecentDocsView*, void*) + 61 54 libvcllo.dylib 0x00000001115214a0 ImplHandleUserEvent(ImplSVEvent*) + 32 55 libvcllo.dylib 0x000000011151f798 ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) + 776 56 libvcllo.dylib 0x00000001117a0a5d SalFrame::CallCallback(SalEvent, void const*) const + 45 57 libvcllo.dylib 0x00000001117a0a19 AquaSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) + 25 58 libvcllo.dylib 0x00000001117a0a9b non-virtual thunk to AquaSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) + 43 59 libvcllo.dylib 0x00000001117135af SalUserEventList::DispatchUserEvents(bool) + 271 60 libvcllo.dylib 0x00000001117a1065 AquaSalInstance::DoYield(bool, bool) + 69 61 libvcllo.dylib 0x0000000111722fa9 ImplYield(bool, bool) + 73 62 libvcllo.dylib 0x0000000111722f04 Application::Execute() + 324 63 libsofficeapp.dylib 0x000000010e12bc53 desktop::Desktop::Main() + 2867 64 libvcllo.dylib 0x0000000111727d8f ImplSVMain() + 79 65 libvcllo.dylib 0x00000001117a0bb7 AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 151 66 libvcllo.dylib 0x00000001117f69e0 -[VCL_NSApplication sendEvent:] + 80 67 com.apple.AppKit 0x00007fff4e43c835 -[NSApplication run] + 812 68 com.apple.AppKit 0x00007fff4e40b9a6 NSApplicationMain + 804 69 libvcllo.dylib 0x000000011179ff22 ImplSVMainHook(int*) + 354 70 libvcllo.dylib 0x0000000111728979 SVMain() + 41 71 libsofficeapp.dylib 0x000000010e15a846 soffice_main + 230 72 org.libreoffice.script 0x000000010e0a7f50 main + 16 73 libdyld.dylib 0x00007fff7838e145 start + 1
I am now editing the headline as it really doesn't seem Java related. And it happens on 6.0alpha1 as well, of course.
no repro w Version: 6.0.0.0.alpha1+ Build ID: 254c49dcceaa8b181b2cb3338e34e5637be277b9 CPU threads: 4; OS: Mac OS X 10.13; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-10-21_04:42:11 Locale: de-DE (de_DE.UTF-8); Calc: group @Martin which macOS are you using? Is the problem persisting using the latest nightly from today?
@Martin : graphics chip hardware ? We have had other reports of some Intel chips on MacOS causing direct crashes on startup or loading a document, or clicking somewhere in the application UI or document work area.
@Alex My graphics: Intel HD Graphics 5000 1536 MB Strange, I have never had such crashes at startup and I have used a big number of alpha and beta versions of LO ... So whatever is causing this, it is connected only with 6.0/master and not with previous versions.
It seems this bug is related to turning on the OpenGL option in the Settings > LibreOffice Dev > View. Strange, LO54 and all previous versions worked fine with this option enabled.
(In reply to Martin Srebotnjak from comment #25) > It seems this bug is related to turning on the OpenGL option in the Settings > > LibreOffice Dev > View. > Strange, LO54 and all previous versions worked fine with this option enabled. I can confirm a crash with OpenGL enabled
NEW per previous comment.
I am not sure if to open a fresh bug report, but unlike beta2 the RC1 keeps crashing when trying to open the Settings dialog (LibreOffice - Settings ...). It happens even in Safe Mode and even with a factory profile. I have concurrent 6.0beta2 on the system and that one works just fine. So should I open a new bug report or will this one be used? However, it does seem non-related to experimental features/OpenGL.
(In reply to Martin Srebotnjak from comment #28) > I am not sure if to open a fresh bug report, but unlike beta2 the RC1 keeps > crashing when trying to open the Settings dialog (LibreOffice - Settings > ...). > It happens even in Safe Mode and even with a factory profile. > I have concurrent 6.0beta2 on the system and that one works just fine. > > So should I open a new bug report or will this one be used? However, it does > seem non-related to experimental features/OpenGL. It's separate bug, already reported: see bug 114655
Also reproduced in Version: 6.0.0.0.alpha1 Build ID: c1d1f859b268f650143d48f294999cda0fa57350 CPU threads: 8; OS: Mac OS X 10.12.6; UI render: GL; Locale: en-US (en_ES.UTF-8); Calc: group
There's now a Windows repro as well, which produces the same backtrace as the one in comment 20, let me close this ticket as duplicate. *** This bug has been marked as a duplicate of bug 114736 ***
This is not the same bug. On OSX it crashes all the time, with any document being opened or created. It is a wider bug. And this one affects only macOS! So I will now reopen it and *ONLY IF* the patch for that bug helps this bug then we can consider closing this ...
Aron Budea closed this bug based on the backtrace, meaning both bugs have the same root cause. As Aron explained, bug 114736 is reproducible on Win, which make the changes of fixing it higher, as most developers work with Linux or Win but not with Mac. I trust Aron's opinion. Closing as duplicated. Once bug 114736 is fixed, I'll personally check whether this one is fixed as well, and if it's not, it will be reopen. This is the same workflow we use for every bug our bugzilla *** This bug has been marked as a duplicate of bug 114736 ***
Back to new again. It's not a CJK UI language + OpenGL (a described in bug 114736 comment 12)
Regression introduced by: author Tamas Bunth <tamas.bunth@collabora.co.uk> 2017-06-08 19:56:28 +0200 committer Tamás Bunth <btomi96@gmail.com> 2017-06-09 16:29:40 +0200 commit f0821f9a347c7752a3c741c3451a2f1630173720 (patch) tree cbc76e9d40d1490af1595556b2c6f877a90f3eb8 parent c8e3fea4996436d1fd608cf5ef0fdc18f5a8fd7f (diff) Cache text layout of statusbar items Extend lifecycle of SalLayout created by the output device. A layout is stored for each status bar item and used as a cache. The layout may be updated through output device method parameters. This way it's no longer necessary to calculate the layout again and again when painting the status bar item multiple times, provided that its text does not change. Bisected with: bibisect-mac64-6.0 Adding Cc: to Tamas Bunth
Created attachment 139244 [details] BT with symbols No crash when opening preferences with OpenGL Version: 6.1.0.0.alpha0+ Build ID: d1bc14b318c9a412a761d243085da0895a1aed4a CPU threads: 4; OS: Mac OS X 10.13.1; UI render: default; Locale: nl-NL (nl_US.UTF-8); Calc: group threaded However, crash while opening Draw
I can reliably reproduce the crash / no crash behaviour as follows: * enable OpenGL and LO crashes during opening of a document and then goes into an endless crash / restart / restore loop * resetting the profile and then NOT enabling OpenGL reliably opens the same documents w/o problems. Clearly a regression since I could run LO with OpenGL enabled on all prior LO versions (which supported OpenGL) on my very same machine. SW: LO 6.0.0.3 (LO 6.0.0 RC3) macOS 10.13.3 Java 8u162 HW: MacBook Pro Retina early 2013, 16GB RAM, Intel HD 4000 and NVIDIA GeForce GT 650M
Hopefully fixed by the build of tomorrow. See bug 114736 https://cgit.freedesktop.org/libreoffice/core/commit/?id=9b5730f92967b6a8f4fce349bcd951f388b940df
*** Bug 115331 has been marked as a duplicate of this bug. ***
Has someone already tested the nightly build as suggested by Telesto?
The crash is still reproducible in Version: 6.1.0.0.alpha0+ Build ID: 3171066a959b52cd483bb22a0d1046e633f092f6 CPU threads: 8; OS: Mac OS X 10.13.2; UI render: GL; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-02-01_07:30:54 Locale: en-US (en_ES.UTF-8); Calc: group
*** Bug 115373 has been marked as a duplicate of this bug. ***
I am the submitter of Bug 115373. V6.0.3 seems to function properly with OpenGL turned off, which, as i see it, isn't a solution but a workaround. Will continue to test. Thank you.
*** Bug 115385 has been marked as a duplicate of this bug. ***
*** Bug 115387 has been marked as a duplicate of this bug. ***
have this in 6 final as well. I can confirm the problem disappears with OpenGL disabled. Since LO has always been shittily choppy on my mac, I thought having some kind of rendering support would be better though....
Thrashed with this problem once I downloaded LO 6 public release. Found this bug from a reply to my query on ask.libreoffice.org (https://ask.libreoffice.org/en/question/144968/lo-6-macos-10133-startup-ask-to-recover-say-no-crash-endless-loop/?sort=latest). Running LO 5.4.4, disabled BOTH OpenCL and OpenGL, then restarted LO 6, no crashes yet. I'm hoping the OpenCL / OpenGL incompatibility on macOS will disappear. Running macOS 10.13.3 (17D47) on a MacBookPro13,2.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c83d2ac99dc3da4ef85b193543a93e02e3858844 tdf#112990: Hack-around: Do not crash on mac with opengl enabled It will be available in 6.1.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=392206f0449f9baa987d28cf509eccfa33700330&h=libreoffice-6-0 tdf#112990: Hack-around: Do not crash on mac with opengl enabled It will be available in 6.0.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.
New install starts in safe mode every time.
(In reply to dragracer.mb from comment #50) > New install starts in safe mode every time. By new install you mean 6.0.1? Please specify.
Sorry, still cannot test, there were no master nor 6.0.x daily builds since you checked in the patches ... Strange.
Hi, Problem still present with latest 6.0.1 release on MacOS High Sierra (Mac book pro retina Late 2013)
Yes, JiCi, the patch was submitted after 6.0.1 was created. We are all waiting for daily 6.0 or master builds to test, but unfortunately none were built after February 8 (unlike Win and Linux). See here: https://dev-builds.libreoffice.org/daily/master/?C=M&O=D https://dev-builds.libreoffice.org/daily/libreoffice-6-0/?C=M&O=D
Ok Martin, Thanks !
Does any1 know why there are no macOS daily builds (6.0 nor master) for a week now? How can we test this? Will there be a 6.0.2 macOS release?
(In reply to Martin Srebotnjak from comment #56) > Does any1 know why there are no macOS daily builds (6.0 nor master) for a > week now? > How can we test this? Will there be a 6.0.2 macOS release? Happens once in a while.. Something with the build bot breaking down. It's annoying, I know. And there surely while be a 6.0.2 release ;-)
*** Bug 115870 has been marked as a duplicate of this bug. ***
I assume this has been fixed by Xisco's patch (comment #48 and 49)? OK to mark as RESOLVED FIXED then?
(In reply to Tor Lillqvist from comment #59) > I assume this has been fixed by Xisco's patch (comment #48 and 49)? OK to > mark as RESOLVED FIXED then? It's a workaround, but yeah, let's close it for the time being...
I think it's not OK to close it because it is only a workaround. Either you open a new bug to tackle the real problem or this bug needs to be re-opened with a new target release. There's already way too much history in not really fixing Mac-related bugs in LibO.
This patch hasn't been even tested on daily builds as they were none available from February 8 yet, so what is the rationale on closing it?
(In reply to Martin Srebotnjak from comment #62) > This patch hasn't been even tested on daily builds as they were none > available from February 8 yet, so what is the rationale on closing it? I tested it locally
You can also use LibreOffice 6.0.2.1 to test it -> https://dev-builds.libreoffice.org/pre-releases/mac/x86_64/LibreOffice_6.0.2.1_MacOS_x86-64.dmg
I can confirm, that with 6.0.2.1 on macOS I do not experience crashes with OpenGL enabled, at least in a few hours of working with the software.
Ok for me too in 6.0.2.1 on macOS High Sierra (MBP Retina Late 2013)
This problem persists in LO 6.3.2 on MacOS High Sierra 10.13.6 (17G8037). Material : MacBookPro13,3, graphics : Radeon Pro 455 2048 Mo & Intel HD Graphics 530 1536 Mo. java version "1.8.0_65" Java(TM) SE Runtime Environment (build 1.8.0_65-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode) Impossible to use LO anymore. To reproduce: - FRESH install of Libre Office 6.3.2 (no extensions, user profile in all ~/Library locations suppressed) - Open LibreOffice - Create new document (writer or calc, does not matter) - Do anything (write text, go into menu) - Crashes after 30 to 60 seconds. Mac bug report: Process: soffice [26916] Path: /Applications/LibreOffice.app/Contents/MacOS/soffice Identifier: org.libreoffice.script Version: 6.3.2002 (6.3.2002) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: soffice [26916] User ID: 502 Date/Time: 2019-10-07 11:27:22.281 +0200 OS Version: Mac OS X 10.13.6 (17G8037) Report Version: 12 Bridge OS Version: 3.0 (14Y901) Anonymous UUID: 29DF5ED0-952B-C746-CBE6-3FFE8AD7E284 Sleep/Wake UUID: 6B6D305E-8CFD-4316-9528-EEBB8A336507 Time Awake Since Boot: 110000 seconds Time Since Wake: 2500 seconds System Integrity Protection: enabled Crashed Thread: 7 UpdateCheckThread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010 Exception Note: EXC_CORPSE_NOTIFY VM Regions Near 0x10: --> __TEXT 0000000108e33000-0000000108e34000 [ 4K] r-x/rwx SM=COW /Applications/LibreOffice.app/Contents/MacOS/soffice Application Specific Information: abort() called ... Thread 7 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x000070000fe0a000 rcx: 0x000070000fe07df8 rdx: 0x0000000000000000 rdi: 0x000000000000da5b rsi: 0x0000000000000006 rbp: 0x000070000fe07e30 rsp: 0x000070000fe07df8 r8: 0x00007fff9b4239e8 r9: 0xffffffff00000000 r10: 0x0000000000000000 r11: 0x0000000000000206 r12: 0x000000000000da5b r13: 0x00007fd22ab0d660 r14: 0x0000000000000006 r15: 0x000000000000002d rip: 0x00007fff62b4bb66 rfl: 0x0000000000000206 cr2: 0x00007fff9b421168 Logical CPU: 0 Error Code: 0x02000148 Trap Number: 133 External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 1 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 75654 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=543.6M resident=0K(0%) swapped_out_or_unallocated=543.6M(100%) Writable regions: Total=550.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=550.3M(100%) VIRTUAL REGION REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= Accelerate framework 384K 3 Activity Tracing 256K 2 CG backing stores 66.4M 13 CG image 13.4M 12 CG raster data 2932K 23 CoreAnimation 212K 8 CoreGraphics 8K 2 CoreImage 28K 4 CoreUI image data 3264K 24 CoreUI image file 340K 6 Dispatch continuations 16.0M 2 Foundation 36K 3 Kernel Alloc Once 8K 2 MALLOC 400.2M 156 MALLOC guard page 48K 9 MALLOC_LARGE (reserved) 25.2M 4 reserved VM address space (unallocated) Memory Tag 242 12K 2 Memory Tag 251 12K 2 SQLite page cache 448K 3 STACK GUARD 56.0M 10 Stack 12.1M 12 VM_ALLOCATE 12.6M 548 __DATA 36.0M 414 __FONT_DATA 4K 2 __GLSLBUILTINS 2588K 2 __LINKEDIT 243.7M 141 __TEXT 299.9M 390 __UNICODE 560K 2 mapped file 1.0G 705 shared memory 3300K 27 =========== ======= ======= TOTAL 2.2G 2503 TOTAL, minus reserved VM space 2.2G 2503 Model: MacBookPro13,3, BootROM 259.71.1.0.0, 4 processors, Intel Core i7, 2.7 GHz, 16 GB, SMC 2.38f7 Graphics: Intel HD Graphics 530, Intel HD Graphics 530, Built-In Graphics: Radeon Pro 455, AMD Radeon Pro 455, PCIe Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320 Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
Crashing on startup is not the same as waiting 30-60 seconds then crashing. The trace in comment 68 clearly shows that the update check thread was running when LO crashed, which is bug 127619. Resolved "fixed" per comment 60