Bug 112990 - LO60master on macOS: crashing at start with OpenGL enabled
Summary: LO60master on macOS: crashing at start with OpenGL enabled
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha1+
Hardware: x86-64 (AMD64) Mac OS X (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.2
Keywords: bibisected, bisected, haveBacktrace, regression
: 115331 115373 115385 115387 115870 (view as bug list)
Depends on:
Blocks: Splash-Screen
  Show dependency treegraph
 
Reported: 2017-10-08 10:12 UTC by Martin Srebotnjak
Modified: 2018-02-27 17:58 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
BT with symbols (1.03 MB, text/rtf)
2018-01-21 16:29 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Srebotnjak 2017-10-08 10:12:03 UTC
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.
Comment 1 Martin Srebotnjak 2017-10-08 10:13:37 UTC
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
Comment 2 Martin Srebotnjak 2017-10-08 21:22:57 UTC
Please someone confirm.
Comment 3 Alex Thurgood 2017-10-09 07:07:22 UTC
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
Comment 4 Alex Thurgood 2017-10-09 07:09:31 UTC
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
Comment 5 Alex Thurgood 2017-10-09 07:16:04 UTC
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
Comment 6 Alex Thurgood 2017-10-09 07:17:31 UTC
@Miles : outside of a possible hardware problem, is it any document that causes the crash, or particular documents ?
Comment 7 Alex Thurgood 2017-10-09 07:19:24 UTC
Note that I took the daily build from the MacOSX-x86_64@49-TDF buildbot
Comment 8 Telesto 2017-10-09 07:20:23 UTC
First thought: bug 103690
Comment 9 Alex Thurgood 2017-10-09 07:29:30 UTC
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
Comment 10 Martin Srebotnjak 2017-10-12 09:53:12 UTC
Who can I send the crash report to? I don't want to publish it here.
Comment 11 Martin Srebotnjak 2017-10-12 09:59:57 UTC
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
Comment 12 Martin Srebotnjak 2017-10-12 10:15:06 UTC
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 ...
Comment 13 Alex Thurgood 2017-10-12 11:49:03 UTC
(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 ?
Comment 14 Martin Srebotnjak 2017-10-12 14:31:55 UTC
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.
Comment 15 Martin Srebotnjak 2017-10-12 14:34:19 UTC
Could this be in any way connected to this (update of hunspell):
https://gerrit.libreoffice.org/#/c/42555/
Comment 16 Martin Srebotnjak 2017-10-12 14:39:31 UTC
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
Comment 17 Alex Thurgood 2017-10-12 16:50:25 UTC
(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 ?
Comment 18 Martin Srebotnjak 2017-10-13 08:44:22 UTC
Maybe the spell-checking/built-in grammar checking uses or at least touches JVM at the start of LO?
Comment 19 Martin Srebotnjak 2017-10-20 13:32:46 UTC
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...
Comment 20 Martin Srebotnjak 2017-10-20 13:39:30 UTC
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
Comment 21 Martin Srebotnjak 2017-10-20 14:15:58 UTC
I am now editing the headline as it really doesn't seem Java related.

And it happens on 6.0alpha1 as well, of course.
Comment 22 steve -_- 2017-10-21 07:21:03 UTC
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?
Comment 23 Alex Thurgood 2017-10-23 09:03:25 UTC
@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.
Comment 24 Martin Srebotnjak 2017-10-30 12:34:33 UTC
@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.
Comment 25 Martin Srebotnjak 2017-11-06 14:52:55 UTC
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.
Comment 26 Telesto 2017-11-18 13:07:09 UTC
(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
Comment 27 Buovjaga 2017-11-18 16:40:36 UTC
NEW per previous comment.
Comment 28 Martin Srebotnjak 2017-12-24 14:38:57 UTC
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.
Comment 29 Telesto 2017-12-24 15:14:35 UTC
(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
Comment 30 Xisco Faulí 2017-12-28 11:39:31 UTC
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
Comment 31 Aron Budea 2017-12-28 19:42:26 UTC
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 ***
Comment 32 Martin Srebotnjak 2017-12-29 00:14:07 UTC
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 ...
Comment 33 Xisco Faulí 2017-12-29 08:38:12 UTC
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 ***
Comment 34 Telesto 2018-01-17 22:09:23 UTC
Back to new again. It's not a CJK UI language + OpenGL (a described in bug 114736 comment 12)
Comment 35 Xisco Faulí 2018-01-18 17:03:32 UTC
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
Comment 36 Telesto 2018-01-21 16:29:35 UTC
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
Comment 37 Frank Fuchs 2018-01-25 20:30:41 UTC
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
Comment 38 Telesto 2018-01-28 15:33:28 UTC
Hopefully fixed by the build of tomorrow. See bug 114736
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9b5730f92967b6a8f4fce349bcd951f388b940df
Comment 39 Xisco Faulí 2018-01-31 15:00:38 UTC
*** Bug 115331 has been marked as a duplicate of this bug. ***
Comment 40 steve -_- 2018-02-01 08:41:11 UTC
Has someone already tested the nightly build as suggested by Telesto?
Comment 41 Xisco Faulí 2018-02-01 09:50:26 UTC
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
Comment 42 Xisco Faulí 2018-02-01 14:07:55 UTC
*** Bug 115373 has been marked as a duplicate of this bug. ***
Comment 43 Grey 2018-02-01 14:23:41 UTC
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.
Comment 44 Aron Budea 2018-02-01 17:38:25 UTC
*** Bug 115385 has been marked as a duplicate of this bug. ***
Comment 45 Xisco Faulí 2018-02-01 22:23:32 UTC
*** Bug 115387 has been marked as a duplicate of this bug. ***
Comment 46 rebastion 2018-02-02 07:41:30 UTC
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....
Comment 47 Smith Kennedy 2018-02-04 20:40:50 UTC
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.
Comment 48 Commit Notification 2018-02-08 15:34:05 UTC
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.
Comment 49 Commit Notification 2018-02-08 22:00:19 UTC
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.
Comment 50 dragracer.mb 2018-02-10 18:21:07 UTC
New install starts in safe mode every time.
Comment 51 Aron Budea 2018-02-10 18:31:35 UTC
(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.
Comment 52 Martin Srebotnjak 2018-02-10 20:58:32 UTC
Sorry, still cannot test, there were no master nor 6.0.x daily builds since you checked in the patches ... Strange.
Comment 53 JiCi 2018-02-10 23:16:00 UTC
Hi,


Problem still present with latest 6.0.1 release on MacOS High Sierra (Mac book pro retina Late 2013)
Comment 54 Martin Srebotnjak 2018-02-11 07:31:55 UTC
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
Comment 55 JiCi 2018-02-11 13:05:18 UTC
Ok Martin, Thanks  !
Comment 56 Martin Srebotnjak 2018-02-16 10:14:45 UTC
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?
Comment 57 Telesto 2018-02-16 11:27:47 UTC
(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 ;-)
Comment 58 Xisco Faulí 2018-02-20 10:50:00 UTC
*** Bug 115870 has been marked as a duplicate of this bug. ***
Comment 59 Tor Lillqvist 2018-02-23 16:25:03 UTC
I assume this has been fixed by Xisco's patch (comment #48 and 49)? OK to mark as RESOLVED FIXED then?
Comment 60 Xisco Faulí 2018-02-23 16:34:24 UTC
(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...
Comment 61 Frank Fuchs 2018-02-24 09:10:27 UTC
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.
Comment 62 Martin Srebotnjak 2018-02-24 09:32:04 UTC
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?
Comment 63 Xisco Faulí 2018-02-24 10:12:40 UTC
(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
Comment 64 Xisco Faulí 2018-02-24 10:31:47 UTC
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
Comment 65 Martin Srebotnjak 2018-02-26 13:51:23 UTC
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.
Comment 66 JiCi 2018-02-27 17:58:07 UTC
Ok for me too in 6.0.2.1 on macOS High Sierra (MBP Retina Late 2013)