Created attachment 126290 [details] LO screen after freezing in Create - Writer Document Hi, I'm using macOS Sierra Public Beta (16A238m). Launch LO (5.1.4 or newer). First action* after launch will freeze LO. * Like LibreOffice - About; LibreOffice - Preferences; Create - Writer Document; Open File Every time after every program launch. Gerald
No way of confirming this until a QAer or dev has access to the beta OSX Sierra. As things can change over the beta testing period, it might be pointless worrying about whether or not LO works on this OS version. Previous OSX beta releases have shown similar behaviour.
Can confirm this is happening on 5.2.0.2 as well on Sierra Public Beta.
Apple has a history of providing beta versions of its future OS that cause LO to hang/crash (past experience has shown this multiple times). Rarely has the same behaviour been confirmed when the final release of the OS is made. That does not mean however, that we should be complacent, so I would encourage all current testers of OSX beta to keep reporting back as versions progress. LibreOffice is never built against the latest beta release of OSX, nor even the latest GA release until either TDF upgrades its build machine(s), or a fearless dev decides to try and build LO and attempt to repair the consequences of Apple's insidious OS API changes or toolchain provision.
*** Bug 101817 has been marked as a duplicate of this bug. ***
Confirmed after duplicate report
This issue still exists with LibreOffice 5.2.1 on macOS 10.12 Golden Master 16A320
yes!!! thank you corrado
yes!!! LibreOffice 5.2.1.2 thank you corrado
Also with build 16A323 thank you corrado
@swrobel or @corrado : Ideally, we would need a backtrace from a lldb debugging session and a debug build enabled version of LibreOffice master daily build. That at least should help us see where LO is failing after launch.
please explain how to do and I do it corrado
Dear all, I experience the same crash on my iMac retina late 2015. But it appears only on my iMac after installation of the GM. On my MacBook Pro (early 2015), also running currently with os X 10.12 GM (and since July with all the betas), it works fine. Benoit
A trigger then this problem could be https://bugs.documentfoundation.org/show_bug.cgi?id=100994 I also MacBook Pro (early 2015)
(In reply to corrado from comment #11) > please explain how to do and I do it > > corrado Hmm, well the usual way would be to find and download a debug-enabled build of master source code tree from here : http://dev-builds.libreoffice.org/daily/master/ However, there don't appear to be any debug-enabled builds in any of the Mac machine directories at present, so you are going to be stuck unless you can build LibreOffice yourself from source. If you do manage to get hold of a recent debug-enabled build for OSX, you can try running it in a lldb debugging session. From the Terminal.app console : lldb /Applications/LibreOfficeDev.app wait for lldb to start and initialize the debugging environment, then at the lldb prompt, type : run and LibreOffice will try and start. If it fails to starts, messages will be displayed on the console output. If you get a message like SIGSEGV or SIGABRT, you could try typing : bt all and pressing enter. It might take some time to produce output on the screen, so be patient. When the output has stopped appearing on the console, you can copy and paste the whole ouptu into a text file, and then attach that file to this bug report. You can quit a lldb session by typing : q and you will be asked if you want to quit the running process (assuming that LO is indeed still running).
Hi, I wished inform you, that I observed by accident that when the language package is not installed, LibreOffice runs well. Best regards Benoit
Created attachment 127502 [details] backtrace
Here is the file I had to close with a "q" nothing happens and the program remained open
(In reply to corrado from comment #17) > Here is the file I had to close with a "q" nothing happens and the program > remained open That's great work, thanks ! It seems from the trace you provided that the memory allocation heap is now verified by the OS (maybe it was also before, but I wouldn't know about that) upon release of memory and that this is no longer coherent with the initial memory allocation heap. Perhaps this is a new security feature of Sierra ?
(In reply to Benoit HILT from comment #15) Hi Benoit, > I wished inform you, that I observed by accident that when the language > package is not installed, LibreOffice runs well. > > Best regards > > Benoit Perhaps we have a problem with the digital signature of our lang-packs again wrt Sierra.
@corrado : do you have a lang-pack installed ? If yes, which one ?
No crash for me with the English version of LibreOffice on Sierra installed today : Version: 5.2.0.4 Build ID: 066b007f5ebcc236395c7d282ba488bca6720265 CPU Threads: 2; OS Version: Mac OS X 10.12; UI Render: default; Locale: en-GB (fr_FR.UTF-8)
No repro with Version: 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 CPU Threads: 2; OS Version: Mac OS X 10.12; UI Render: default; Locale: en-GB (fr_FR.UTF-8); Calc: group Mac mini Server (mi-2010) 2,66 GHz Intel Core 2 Duo 4 Go 1067 MHz DDR3 NVIDIA GeForce 320M 256 Mo
Setting back to NEEDINFO and lowering priority @corrado : I see no crash with GA OSX 10.12 and latest stable production release of LibreOffice on my hardware. There must be something else that triggers the crash. @swrobel : we need your input on this too @gerald : please provide an update with regard to your installation Please indicate whether you have installed any language packs, and if so, which ones.
Also tested with Version: 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 Threads CPU : 2; Version de l'OS :Mac OS X 10.12; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group after installing FR lang pack and setting language and UI to French. No crash.
Neither master nor MAS version 5.2.1.2 crashing on 10.12.
(In reply to steve -_- from comment #25) > Neither master nor MAS version 5.2.1.2 crashing on 10.12. Thansk Steve, I fear that this may be much ado about nothing, but let's wait for the other reporters to get back before we close as WFM.
Hi, I can confirm that I get this error on the public release of Sierra. I am using an iMac Retina 5k, 27-inch, Late 2015, 3.2GHz intel core i5. I logged a bug about it here https://bugs.documentfoundation.org/show_bug.cgi?id=102349 - I don't know if I should remove it given that I have the error on the full release version rather than the beta...
I can confirm such behaviour when opening existing or creating new Writer document. LO freezes while console is flooded with the messages originating from kernel process (about 15 messages per millisecond): AMFI: allowing exception handler for 'soffice' (PID) because the process is not restricted. HW: iMac Retina 5k, Late 2015, macOS Sierra 10.12 (16A323) - general public release
*** Bug 102349 has been marked as a duplicate of this bug. ***
Given the nnumber of duplciates, setting to NEW, resetting priorities
*** Bug 102361 has been marked as a duplicate of this bug. ***
@all those who reported freezes : what are the graphics chips in those iMac 5K devices ?
(In reply to corrado from comment #16) > Created attachment 127502 [details] > backtrace Corrado: What LO version do you use? Indeed, master sources show line 1409 instead of 330 for AquaSalGraphics::drawPolyLine(unsigned int, SalPoint const*) (a function from your bt) http://opengrok.libreoffice.org/xref/core/vcl/quartz/salgdicommon.cxx#1409
I gave a try with: https://gerrit.libreoffice.org/#/c/29194/ See comments on patch itself.
*** Bug 102380 has been marked as a duplicate of this bug. ***
AMD Radeon R9 M395 2048 MB iMAc 5k late 2015
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5333743d3b8288fb40e4657aedf1db2255f6a62b tdf#100994: use CGContextStrokePath instead It will be available in 5.3.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.
I have the same issue: just updated to the public Macos Sierra and LibreOffice hangs on opening documents. Versions tested: 5.2.5 and 5.30 (23 Sept DEV version) Terminal output: $ /Applications/LibreOfficeDev.app/Contents/MacOS/soffice [very long output; and upon opening the About screen - freeze:] warn:opencl:4977:1:desktop/source/app/opencl.cxx:138: Failed to initialize OpenCL for test soffice(4977,0x7fffa006b3c0) malloc: *** error for object 0x7f9dbea38a00: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug
Created attachment 127584 [details] LO dev terminal output, persistent freeze on macos sierra
Just tested 5.30, it don´t work. Freeze down. The icons at the toolbar don´t look as they used to.
(In reply to Ralf Roth from comment #40) > Just tested 5.30, it don´t work. Freeze down. The icons at the toolbar don´t > look as they used to. Just to be sure the last part, you mean it's worse with the patch (and so there's a regression)?
Downloaded and ran: master~2016-09-25_07.02.24_LibreOfficeDev_5.3.0.0.alpha0_MacOS_x86-64.dmg Experienced similar crash when selecting About LibreOffice that I experienced with the current release (lldb) target create "/Applications/LibreOfficeDev.app/" Current executable set to '/Applications/LibreOfficeDev.app/' (x86_64). (lldb) run Process 28001 launched: '/Applications/LibreOfficeDev.app/Contents/MacOS/soffice' (x86_64) warn:sal.osl.pipe:28001:1:sal/osl/unx/pipe.cxx:395: shutdown() failed: Socket is not connected Process 28001 exited with status = 0 (0x00000000) (lldb) run Process 28014 launched: '/Applications/LibreOfficeDev.app/Contents/MacOS/soffice' (x86_64) soffice(28014,0x7fffdf7993c0) malloc: *** error for object 0x1110c3c00: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Process 28014 stopped * thread #1: tid = 0xecf7c, 0x00007fffd6bc4dda libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fffd6bc4dda libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fffd6bc4dda <+10>: jae 0x7fffd6bc4de4 ; <+20> 0x7fffd6bc4ddc <+12>: movq %rax, %rdi 0x7fffd6bc4ddf <+15>: jmp 0x7fffd6bbdd6f ; cerror_nocancel 0x7fffd6bc4de4 <+20>: retq
Ok so the patch changes nothing at all. Let's remove target then.
(In reply to Dana Weick from comment #42) @Dana : please provide your hardware specification (processor, graphics chip, memory, etc) screen type and screen resolution.
(In reply to Ralf Roth from comment #40) > Just tested 5.30, it don´t work. Freeze down. The icons at the toolbar don´t > look as they used to. @Ralf : the icon issue is bug 100995
Created attachment 127638 [details] LibreOffice persistent hang on mnacos Sierra oniMac retina 5k LO keeps freezing on Sierra. Version tested: LO dev master~2016-09-25_23.40.02_LibreOfficeDev_5.3.0.0.alpha0_MacOS_x86-64.dmg lldb output attached. Hardware Overview: Model Name: iMac Model Identifier: iMac17,1 Processor Name: Intel Core i7 Processor Speed: 4 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 8 MB Memory: 32 GB System Software Overview: System Version: macOS 10.12 (16A323) Kernel Version: Darwin 16.0.0
(In reply to joostjodel from comment #48) > Created attachment 127638 [details] > LibreOffice persistent hang on mnacos Sierra oniMac retina 5k > > LO keeps freezing on Sierra. > Version tested: LO dev > master~2016-09-25_23.40.02_LibreOfficeDev_5.3.0.0.alpha0_MacOS_x86-64.dmg > > lldb output attached. > > Hardware Overview: > > Model Name: iMac > Model Identifier: iMac17,1 > Processor Name: Intel Core i7 > Processor Speed: 4 GHz > Number of Processors: 1 > Total Number of Cores: 4 > L2 Cache (per Core): 256 KB > L3 Cache: 8 MB > Memory: 32 GB > > > System Software Overview: > > System Version: macOS 10.12 (16A323) > Kernel Version: Darwin 16.0.0 Further hardware specification: graphics chip - AMD Radeon R9 M395 2048 MB graphics screen type - Built-in Retina Display 27-inch (5120 x 2880) screen resolution - 5120 x 2880
Mac mini (Late 2012) 2.3 GHz INtel Core i7 16 GB 1600 MHz DDR3 Intel HD Graphics 4000 1536 MB
screen resolution 2560x1440
I downloaded master~2016-09-25_23.40.02_LibreOfficeDev_5.3.0.0.alpha0_MacOS_x86-64.dmg and the application still freezes on first action. macOS Sierra Version 10.12. AMD Radeon R9 M380 2048 MB graphics on retina display (5120x2880).
MacBook Pro (13-inch, Early 2011) Intel HD Graphics 3000 384 MB LO 5 several versions up to 5.2.1 MacOS Sierra production version. Seems to be related to screen resolution and icon Bug 100995: works fine when using internal display (non-Retina, 1280x800), but freezes when using external display at 2560x1440. When document window is opened on internal display and then external screen is connected as default, freeze together with spoiled icons occur after trying to resize the window. No crash, but when started from Terminal, malloc error is displayed: soffice(6012,0x7ffff44b53c0) malloc: *** error for object 0x7feb9e679800: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug
it's true!!! without the external monitor also works for me even tweak the 5.2.1.2 version. Beta 10.12.1 (16B2327e) Retina, 13-inch, Early 2015 Intel Iris Graphics 6100 1536 MB
I add that even the icons are seen correctly
Interesting. That made me think: could this have something to do with the pixel doubling on mac retina screens? (see http://www.anandtech.com/show/5996/how-the-retina-display-macbook-pro-handles-scaling). So I tried all the different screen scales available. I even installed a neat little app called SwitchResX to set the native iMac retina 5120 x 2880 resolution, which the Macos preferences doesn't let you do. Unfortunately, in all cases the same ol' freeze upon opening the About screen: $ lldb /Applications/LibreOfficeDev.app (lldb) target create "/Applications/LibreOfficeDev.app" Current executable set to '/Applications/LibreOfficeDev.app' (x86_64). (lldb) run Process 3799 launched: '/Applications/LibreOfficeDev.app/Contents/MacOS/soffice' (x86_64) soffice(3799,0x7fffd282d3c0) malloc: *** error for object 0x111926400: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Process 3799 stopped * thread #1: tid = 0xb3c84, 0x00007fffc9c66dda libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fffc9c66dda libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fffc9c66dda <+10>: jae 0x7fffc9c66de4 ; <+20> 0x7fffc9c66ddc <+12>: movq %rax, %rdi 0x7fffc9c66ddf <+15>: jmp 0x7fffc9c5fd6f ; cerror_nocancel 0x7fffc9c66de4 <+20>: retq (lldb)
I do not use any scaling, all screens are set to Best for display. The external screen is physically about 4 times bigger than the 13" lid, so the larger number of pixels results in roughly same DPI anyway.
I would like to add that running master~2016-09-28_02.16.45_LibreOfficeDev_5.3.0.0.alpha0_MacOS_x86-64_langpack_en-US.dmg in lldb repeatedly results in crashing in different places. The malloc error message is similar, but backtrace is different.
Created attachment 127714 [details] backtraces from repeated runs
I'm not sure if this adds useful information or not. Mid-2012 non-retina MacBook Pro with Dell U3014 Monitor. Works fine without external monitor or if external monitor is scaled to 2048 x 1280 or less. Fails if monitor is run at native 2560 x 1600 resolution Model Name: MacBook Pro Model Identifier: MacBookPro9,1 Processor Name: Intel Core i7 Processor Speed: 2.7 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 8 MB Memory: 16 GB Boot ROM Version: MBP91.00D3.B0D SMC Version (system): 2.1f175 Intel HD Graphics 4000: Chipset Model: Intel HD Graphics 4000 Type: GPU Bus: Built-In VRAM (Dynamic, Max): 1536 MB Vendor: Intel (0x8086) Device ID: 0x0166 Revision ID: 0x0009 Automatic Graphics Switching: Supported gMux Version: 1.9.23 Metal: Supported NVIDIA GeForce GT 650M: Chipset Model: NVIDIA GeForce GT 650M Type: GPU Bus: PCIe PCIe Lane Width: x8 VRAM (Total): 1024 MB Vendor: NVIDIA (0x10de) Device ID: 0x0fd5 Revision ID: 0x00a2 ROM Revision: 3682 Automatic Graphics Switching: Supported gMux Version: 1.9.23 Metal: Supported Displays: DELL U3014: Resolution: 2560 x 1600 @ 60 Hz Pixel Depth: 32-Bit Color (ARGB8888) Display Serial Number: P1V6N55Q544L Main Display: Yes Mirror: Off Online: Yes Rotation: Supported Automatically Adjust Brightness: No Connection Type: DisplayPort Television: Yes
Hi, I have the same trouble after installing macOS Sierra on an MacBook 15" without Retina in a slightly different way: Starting LibreOffice for the first time after installation all works fine, but if I start it for the second time, it immediately crashes (stack trace below). I tried 10.12 als well as 10.12.1 and 5.2.0, 5.2.1, and 5.2.2. Stack trace (for 5.2.2.2): Process: soffice [2322] Path: /Applications/LibreOffice.app/Contents/MacOS/soffice Identifier: org.libreoffice.script Version: 5.2.2002 (5.2.2002) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: soffice [2322] User ID: 501 Date/Time: 2016-10-02 18:05:43.225 +0200 OS Version: Mac OS X 10.12.1 (16B2333a) Report Version: 12 Anonymous UUID: F0D4DF8C-F041-8445-F8B0-EFA1C160EA85 Sleep/Wake UUID: 14556F5D-FE21-4100-B906-B73F4CF33B0B Time Awake Since Boot: 2800 seconds Time Since Wake: 1000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0] VM Regions Near 0: --> __TEXT 0000000100416000-0000000100417000 [ 4K] r-x/rwx SM=COW /Applications/LibreOffice.app/Contents/MacOS/soffice Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libvcllo.dylib 0x0000000102e5e19d Application::GetSolarMutex() + 13 1 libvcllo.dylib 0x0000000102f30e7f -[VCL_NSApplication screenParametersChanged:] + 15 2 com.apple.CoreFoundation 0x00007fff863b16ac __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 3 com.apple.CoreFoundation 0x00007fff863b15ab _CFXRegistrationPost + 427 4 com.apple.CoreFoundation 0x00007fff863b1312 ___CFXNotificationPost_block_invoke + 50 5 com.apple.CoreFoundation 0x00007fff8636fa32 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 2018 6 com.apple.CoreFoundation 0x00007fff8636ea1b _CFXNotificationPost + 667 7 com.apple.Foundation 0x00007fff87d9b0e3 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 8 com.apple.AppKit 0x00007fff843cc650 -[NSApplication _reactToScreenInvalidationImmediately:] + 399 9 com.apple.AppKit 0x00007fff843cc48d __44-[NSApplication _reactToScreenInvalidation:]_block_invoke + 59 10 com.apple.CoreFoundation 0x00007fff863bb3cc __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 11 com.apple.CoreFoundation 0x00007fff8639c6f4 __CFRunLoopDoBlocks + 356 12 com.apple.CoreFoundation 0x00007fff8639c236 __CFRunLoopRun + 1894 13 com.apple.CoreFoundation 0x00007fff8639b874 CFRunLoopRunSpecific + 420 14 com.apple.HIToolbox 0x00007fff8593863c RunCurrentEventLoopInMode + 240 15 com.apple.HIToolbox 0x00007fff85938379 ReceiveNextEventCommon + 184 16 com.apple.HIToolbox 0x00007fff859382a6 _BlockUntilNextEventMatchingListInModeWithFilter + 71 17 com.apple.AppKit 0x00007fff84022b09 _DPSNextEvent + 1093 18 com.apple.AppKit 0x00007fff84737dbf -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1637 19 com.apple.AppKit 0x00007fff840174d5 -[NSApplication run] + 926 20 com.apple.AppKit 0x00007fff83fe2177 NSApplicationMain + 1237 21 libvcllo.dylib 0x0000000102edb7cd ImplSVMainHook(int*) + 397 22 libvcllo.dylib 0x0000000102e62d5a SVMain() + 26 23 libsofficeapp.dylib 0x00000001004c4e8b soffice_main + 219 24 org.libreoffice.script 0x0000000100416f20 main + 16 25 libdyld.dylib 0x00007fff9b4c8255 start + 1
*** Bug 102925 has been marked as a duplicate of this bug. ***
*** Bug 102935 has been marked as a duplicate of this bug. ***
*** Bug 102949 has been marked as a duplicate of this bug. ***
Just though you might not be aware of something as this bug seems to have been ongoing for a while. After going through all the hassle of completely removing the app, including all the application support files in my own folder. On reinstall LO does work, and I can open and close files without any issue. The issue comes when I quit LO and try to restart it. It will always crash. this makes no difference if I use the 'Fresh' or the 'Still' version. If I want the app to work again I have to run the install again. It will work once, but next time I quit the app it will crash. The one thing I did discover is that if I expand the DMG file, and run LO directly from the virtual disk, it will work every time it is started but only if I don't run the installed version, only the copy contained within the virtual disk.
(In reply to Murray Mitchell from comment #65) > > The one thing I did discover is that if I expand the DMG file, and run LO > directly from the virtual disk, it will work every time it is started but > only if I don't run the installed version, only the copy contained within > the virtual disk. Possibly due to the non-writable storage nature of a DMG ? The image file is write-protected by default, if I've understood correctly, whereas the app installed on the hard disk is free to attempt to allocate memory segments in places as it sees fit. It would appear that Sierra no longer seems to allow such behaviour, hence the malloc segfaults ?
TBH, I think you're all looking in the wrong place. I have found a work around which is working for me.
Hi, Il seems that the pb occurs when the GPU switches on dual GPU systems : - from internal GPU (i.e. Intel HD Graphics) ; - to dedicated GPU (i.e. AMD Radeon HD) ; When i enforce dedicated GPU before launching LO, it runs fine. If i use internal GPU, then launch LO, it turns on dedicated GPU and then crash(afterward internal GPU switch back). I think that sierra has changed the initialization process during GPU switching. Launching LO always trigger switch to dedicated GPU. I ca'm using LO 5.2.2.2
Hi, It seems that crash occurs when the GPU switches on dual GPU systems : - from internal GPU (i.e. Intel HD Graphics) ; - to dedicated GPU (i.e. AMD Radeon HD) ; When i enforce dedicated GPU before launch of LO, it runs fine. If i use internal GPU, then launch LO, it turns on dedicated GPU and then crash(afterward internal GPU switch back). I think that MacOs Sierra has changed the initialization process during GPU switching. Launching LO always trigger switch to dedicated GPU. I can use LO 5.2.2.2 without crash enforcing dedicated GPU before launch. I used gfxCardStatus 2.3 switching tool to enforce dedicated GPU. I hope my experience could help, Regards
I have found some interesting parts in one of gfxCardStatus's bug reports. A lot of noise in there, but this looks useful: https://github.com/codykrieger/gfxCardStatus/issues/240#issuecomment-250912849 Something in OSX's GPU selector mechanic was changed in Sierra, which could be interfering with LibreOffice. Building with new tools might be worth a first try. (disclaimer: I have no Mac experience, just trying to interpret the information available) Additionally, bug 103055 seems to be related.
I get the same crash with macbook pro mid 2010 with discrete graphic card. Mine's is nvidia geforce 330M. I can switch on the discrete graphic card by lauching Photos. After that the libreoffice works well. I disabled gfxCardStatus just to see if it would change the situation. I tried with various "fresh" releases of libreoffice. I will try 5.3 beta and report back but now I need the Mac for work. If I may add a cent, it started (for me) after the ugprade from 5.2.0.4 to 5.2.2 but not after upgrading to Sierra. After the first crash, even a restore of libreoffice from time machine sorted out nothing. Libreoffice crashes with or without the language pack.
I also checked that UseOpenGL, ForceOpenGl and UseOpenCL flags are set to "false". Maybe those flags are not taken into account and the graphic card is switched on anyway.
*** Bug 103055 has been marked as a duplicate of this bug. ***
A possible solution seems to be given in this comment : https://github.com/codykrieger/gfxCardStatus/issues/240#issuecomment-226488824 i.e. adding the required keyword to the info.plist file when building the release packages. @Norbert : what do you reckon ?
Reading https://github.com/codykrieger/gfxCardStatus/issues/240#issuecomment-249239664 would appear to indicate that a recompile with current SDK and XCode tools might resolve the problem - AFAIK we currently build our production releases with 10.8 SDK, another argument in favour of dropping that for an uptodate one ? However, that would lead to the question of whether the app would continue to function correctly for older versions of OSX. So, it's a catch-22 kind of situation.
I hope its not obsolete at the current stage, but I can confirm this issue on my MacPro (late 2013) with the AMD FirePro D700 graphics card. So it might not only affect laptops switching to dedicated GPUs but all dedicated GPUs. After the upgrade from 10.11 to 10.12 the issue started immediately. I even erased my disk and performed a clean reinstall (no Time Machine restore) to no avail. If compiling with the latest XCode could break backward compatibility, there is still the option to have 2 releases, one with XCode 10.8 (for 10.8-10.11) and one for 10.12+ using the latest XCode. Would that make sense? I have seen it for other products too, that they provide multiple releases due to API changes etc. Ronny
I agree with Ronny Bremer: two versions are an acceptable solution, no? I tried building LibreOffice myself on macOS Sierra 10.12 with XCode 8 (retina iMac), using the "Quick Pre-canned Setup" instructions on https://wiki.documentfoundation.org/Development/BuildingOnMac. It failed to build, after compiling for a long time. I had to do the following to debug: make CppunitTest_sw_ww8export CPPUNITTRACE="lldb --" and when I ran this program through lldb > run ~/builds/lode/dev/core/workdir/LinkTarget/Executable/cppunittester it gave me a familiar malloc error: cppunittester(19344,0x7fffc75403c0) malloc: *** error for object 0x10419b800: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Process 19344 stopped * thread #1: tid = 0x1a5875, 0x00007fffbe979dda libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fffbe979dda libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fffbe979dda <+10>: jae 0x7fffbe979de4 ; <+20> 0x7fffbe979ddc <+12>: movq %rax, %rdi 0x7fffbe979ddf <+15>: jmp 0x7fffbe972d6f ; cerror_nocancel 0x7fffbe979de4 <+20>: retq (lldb)
I was able to test my Mac Mini that I reported had LibreOffice crashing when running over DisplayPort to a 2560x1440 monitor with a 1080p monitor over HDMI. No crashes with the 1080p monitor and all the icons are correctly scaled as well. My Mac Mini, as I previously reported, only has the integrated Intel HD Graphics 4000 graphics.
(In reply to joostjodel from comment #77) > I tried building LibreOffice myself on macOS Sierra 10.12 with XCode 8 > (retina iMac), using the "Quick Pre-canned Setup" instructions on > https://wiki.documentfoundation.org/Development/BuildingOnMac. > > It failed to build, after compiling for a long time. It will build on Sierra, however, there are known random crashes in the unit test builds (which is one of the one you mention) invoked by default by the make command. You can try and build these separately, using : make unit-test-name and seeing if it completes without errors, then continuing the main build with make. Or, you try the whole LO build with : make build-nocheck to avoid the unit tests from being built.
Thank you Alex, I much appreciate your swift responses and instructions. iMac retina, with AMD Radeon R9 M395 2048 MB card XCode 8.0 $ java -version java version "1.8.0_102" Java(TM) SE Runtime Environment (build 1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode) I followed your instructions: 1. tried compiling separate units (those crashing were among others CppunitTest_sw_ww8export CppunitTest_sw_macros_test CppunitTest_sw_odfimport CppunitTest_sw_ooxmlimport) These all failed however on separate build attempts: make <unit> 2. Continued with $ make. This (of course) failed again. 3. Continued with $ make build-nocheck ; this resulted in an app package. It loads, but again still crashes on the first action, like opening the about screen or opening a document. Maybe now also because of the units that failed to build and were not included in the package? There seems to be some reference to them in the lldb output: $ lldb /Users/me/builds/lode/dev/core/instdir/LibreOfficeDev.app (lldb) target create "/Users/me/builds/lode/dev/core/instdir/LibreOfficeDev.app" Current executable set to '/Users/me/builds/lode/dev/core/instdir/LibreOfficeDev.app' (x86_64). (lldb) run Process 25624 launched: '/Users/me/builds/lode/dev/core/instdir/LibreOfficeDev.app/Contents/MacOS/soffice' (x86_64) warn:sfx.dialog:25624:1:sfx2/source/dialog/filtergrouping.cxx:358: already have an element for WordPerfect warn:sfx.dialog:25624:1:sfx2/source/dialog/filtergrouping.cxx:358: already have an element for writerweb8_writer_template warn:sfx.dialog:25624:1:sfx2/source/dialog/filtergrouping.cxx:358: already have an element for writerglobal8 2016-10-10 17:29:54.641492 soffice[25624:3214102] [default] Failed to updated bookmark for item <private> with error <private> 2016-10-10 17:29:55.140788 soffice[25624:3214101] [default] Failed to updated bookmark for item <private> with error <private> warn:unotools.config:25624:1:unotools/source/config/configitem.cxx:431: ignoring XHierarchicalNameAccess to /org.openoffice.Office.Compatibility// Exception: warn:unotools.config:25624:1:unotools/source/config/configitem.cxx:431: ignoring XHierarchicalNameAccess to /org.openoffice.Office.Compatibility// Exception: warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 5618 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 5618 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 2749 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 5618 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 5618 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 2749 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 3198 warn:oox:25624:1:oox/source/docprop/docprophandler.cxx:314: OOXMLDocPropHandler::startFastElement: unknown element 3198 0x144c8fdf0:createUnknownChildContext:b:Sources 0x144c93198:start unknown element:b:Sources 0x144c93198:end unknown element:b:Sources warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:writerfilter:25624:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:573: no context of type 1 available warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:legacy.osl:25624:1:writerfilter/source/dmapper/StyleSheetTable.cxx:1580: Exception in StyleSheetTable::getOrCreateCharStyle - Style::setPropertyValue warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: HorizontalBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: VerticalBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: BottomBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: LeftBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: RightBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: TopBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: HorizontalBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: VerticalBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: BottomBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: LeftBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: ParaBottomMargin. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: ParaLineSpacing. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: RightBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: TopBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: HorizontalBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: VerticalBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: BottomBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: LeftBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: RightBorder. Message: warn:sw.uno:25624:1:sw/source/core/unocore/unotext.cxx:2289: Exception when setting property: TopBorder. Message: warn:oox:25624:1:oox/source/drawingml/shapecontext.cxx:126: ShapeContext::onCreateContext: unhandled element: 3972 warn:oox:25624:1:oox/source/drawingml/shapecontext.cxx:126: ShapeContext::onCreateContext: unhandled element: 3973 warn:legacy.osl:25624:1:oox/source/helper/storagebase.cxx:67: StorageBase::StorageBase - missing base input stream soffice(25624,0x7fffc75403c0) malloc: *** error for object 0x11baa2e00: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Process 25624 stopped * thread #1: tid = 0x310ab6, 0x00007fffbe979dda libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fffbe979dda libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fffbe979dda <+10>: jae 0x7fffbe979de4 ; <+20> 0x7fffbe979ddc <+12>: movq %rax, %rdi 0x7fffbe979ddf <+15>: jmp 0x7fffbe972d6f ; cerror_nocancel 0x7fffbe979de4 <+20>: retq (lldb)
(In reply to Alex Thurgood from comment #79) Hi Joost, try a : make clean before attempting a rebuild with : make build-nocheck If you haven't re-pulled from the LO git repository recently, do that after "make clean" and before re-attempting your build with "make build-nocheck". Bear in mind that the whole point of the unit tests that are run with a default "make" is to at least check whether the app can launch. It might well be that the unit tests are failing because they expect a particular graphics chip mode that the OS isn't providing, in which case we are stuck until someone can fix them.
Hi together, seems a bit late given the actual comments, but I can also confirm that the bug disappeared when I fixed my MacBook pro to age dedicated graphic card. I also made a test "just for interest" and tried to start OpenOffice (4.1.2). Has the same result. With fixed graphic card, things work, but with switching card, OpenOffice crashes too. So the code in question seems to be located in the common base. Albert
*** Bug 103153 has been marked as a duplicate of this bug. ***
For those with dual graphics chips that aren't flaky/broken, etc, can any of you check whether the option "Automatic graphics switching" is (de)activated under Energy Saver in the General System Preferences ? Please also report whether toggling this option solves the problem.
(In reply to Alex Thurgood from comment #84) > > For those with dual graphics chips that aren't flaky/broken, etc, can any of > you check whether the option "Automatic graphics switching" is (de)activated > under Energy Saver in the General System Preferences ? > > Please also report whether toggling this option solves the problem. I can confirm turning off "Automatic graphics switching" solves the problem. LibreOffice launches and runs without issues. Turning the option back on, it will go back to crashing on launch.
I can confirm it too on my nvidia 330M macbook pro.
(In reply to J L from comment #85) > > I can confirm turning off "Automatic graphics switching" solves the problem. > LibreOffice launches and runs without issues. Turning the option back on, it > will go back to crashing on launch. Excellent ! A big thank you to you and Luca for reporting back. At least we have a workaround for the Macbooks. Reducing severity and priority slightly as a result of this feedback.
(In reply to Alex Thurgood from comment #87) > Reducing severity and priority slightly as a result of this feedback. Erm, and leaving behind all iMacs and Mac Pros? This is one of the most critical and high priority bugs you should process, as it totally prevents the use of LO and those systems.
If I may add my thought, this is a less than trivial workaround for many people and might be a stop for libreoffice diffusion in Mac environment. "It just works" Apple's motto could be a double bladed knife, in this case.
I found this thread of a similar issue with a different software product: https://discourse.mcneel.com/t/rhino-vs-macos-sierra-crash/37061/27 "We are continuing to work on this issue. We do not yet know exactly what is causing the crash, but we are getting closer. We believe this is related to support the "improved support" for extended-range pixel formats and wide-gamut color spaces that are found on the newer iMac 5k displays. It is possible this is something that Apple needs to fix, but we may be able to work around it (if we can reproduce it) now that we can reproduce it on our new(ish) iMac 5k. @philw Can I please get a copy of your calibrated color profile that is causing the crash? We are working get our hands on a 5k iMac where this crash is occurring, but we will need a color profile that is causing the crash to reproduce it (the default does not seem to crash). I believe you can export these profiles using the ColorSync utility. In the meantime, for users that are experiencing the crash (likely on a 5k iMac), please change your color profile (System Preferences > Display > Color) to the Standard iMac Apple RGB profile for the time being." I don't currently have access to my 2560x1440 external display for my Mac Mini so I am unable to do any additional testing, but if anyone is able to install and run the MacOS 10.12.1 Beta and confirm whether or not the problem still exists it might be useful.
(In reply to Dana Weick from comment #90) > In the meantime, for users that are experiencing the crash (likely on a 5k > iMac), please change your color profile (System Preferences > Display > > Color) to the Standard iMac Apple RGB profile for the time being." Yeah. Setting this to "Apple RGB" leads to a working LO on iMac 5k. Switching back to "iMac" results in a freeze after the next action in LO.
Indeed I can confirm that comment #90 & 91 seem to provide a workaround. Setting the color profile to Apple RGB results in no more freezes for me, after some quick testing. No lldb output in terminal either. @Alex comment #81: thanks for the extra instructions. I haven't been able to recompile. I guess however that this sheds new light on the matter.
*** Bug 103201 has been marked as a duplicate of this bug. ***
For me too, if I change the colour profile to Apple I can now use LibreOffice again without crashes :) I'm not convinced that the bug should have been downgraded in importance. Libreoffice still will crash out of the box for all recent iMac users, of whom only a vanishingly small amount will find out how to get it fixed. In any event, thanks to everyone for pitching in to find this work around - I need LibreOffice for actual work.
Created attachment 128012 [details] sampling done while hanging
confirmed that changing the color space (I picked adobe-1998 to try) hang. I've attached a sampling of the app while hung. there is a abort() in the call stack withing a system memory operation, which dead-lock in the signal handler because it try to allocate memory and at that point the memory system is already under it's own lock.
The color space I am using on MacBook Pro mid 2010 with discrete graphic card was already at its default (it is named "LCD display") when crash started to occur. In my case problem did not arose when installed Sierra but when I upgraded LibreOffice. After that there has be no way to fix it, even restoring old versions from time machine. I my case is the switching of the graphic card. Maybe Retina display relying on Radeon rather than Nvidia cards behave different.
Another confirm, MBP 2011, non-Retina. Setting color profile to "Color LCD" (which is default for built-in display) or "Generic RGB" works, the calibrated ones provided by the external monitor and Adobe 1998 don't. No dual graphic card in my machine, so no possibility to swich them. For those trying to recompile from source - I had to re-run configure with "--disable-firebird-sdbc --with-galleries=no" for successfull build, but the result wasn't different from the precompiled development builds.
Thanks Norbert: 2268 free_small (in libsystem_malloc.dylib) + 721 [0x7fffa73e7c66] 2268 small_free_list_remove_ptr_no_clear (in libsystem_malloc.dylib) + 766 [0x7fffa73e7979] 2268 szone_error (in libsystem_malloc.dylib) + 626 [0x7fffa73e5fb1] 2268 abort (in libsystem_c.dylib) + 129 [0x7fffa72eb440] strongly suggests a generic heap corruption; the question is - do we have a valgrind equivalent on Mac to try to find that heap corruption ? without that we're going to struggle I suspect.
(In reply to Michael Meeks from comment #99) > strongly suggests a generic heap corruption; the question is - do we have a > valgrind equivalent on Mac to try to find that heap corruption ? without > that we're going to struggle I suspect. Valgrind is only supported on OSX 101.10, with preliminary support for 10.11 (per http://valgrind.org/downloads/current.html#current), so no cigar there for 10.12. The only other alternative would be via some way of using Instruments.app to do that, but I don't know how.
MacOS has built-in tools for checking heap corruption. See: https://developer.apple.com/library/content/technotes/tn2124/_index.html (look at "Enabling Debugging Facilities">"Environment Variables" and "BSD">"Memory Allocator") and the man page: $ man 3 malloc Try setting MallocGuardEdges, MallocStackLogging and MallocScribble. Lars
*** Bug 103357 has been marked as a duplicate of this bug. ***
I suspect multiple unrelated problems are being reported in the comments here. Only the problem that goes away by using the default colour profile for the display is what *this* bug report should be about. I think the colour profile related bug can be resolved as NOTOURBUG, but let's wait and see if the upcoming 10.12.1 fixes the problem. (If it does, clearly this is/was NOTOURBUG.)
Tor: So if dev department thinks this is Apples bug, has it been reported to Radar, their bug tracking system? If yes, what ID does the report have. If no, how is Apple supposed to know about "their" bug? Also if this is apples bug, other software should face similar issues? Are you aware of other cases (other software) related to this bug on apples side? Also betas for 10.12.1 exist so this should be easy to check if 10.12.1b5 changes anything for the better. Since poor contributors like me only use old macs I am not affected by this bug. Anybody in cc: here w access to the apple developer program, can you check how the 10.12.1 betas behave?
This problem started with the switching of the discrete graphic card, then the title WAS CHANGED and now regards the color space. There are still mine and other's consideration about the discrete graphic card written on this thread. Maybe a better solution would be merge the thread titles, because a moderator sent me here because "duplicate thread". By the way the problem still exit on latest beta: if the DISCRETE GPU is on everything goes smooth, if it now LO crashes. Macbook pro mid 2010, Nvidia 330m.
I am no friggin' "dev department".
Thanks to your attitude, I removed myself from the CC list. Hope this helps, have a nice day.
Steve, Yes, other software has experienced similar issues, see my comment #90. It seems reasonable to wait for Apple's upcoming update, it is just a week or two from release, and at that point determine what remains unresolved.
Dana, I tried to change the color space of my configuration to RGB with no success. My mac runs with the apple's default, which in my case seems to be "LCD Display", but has the issue anyway. The only way to get rid of it, in my case, seems to be the activation of the discrete GPU, by mean of launching Photo or by gfxCardStatus.
12.10.1 is out, any additional testing on 10.12.1 from affected users highly welcome.
Just tested LO 5.2.1.2 on Sierra 10.12.1, iMac 5k with default "iMac" monitor profile and so far everything works as expected.
*** Bug 103408 has been marked as a duplicate of this bug. ***
I just tried with and the issue is still there: - If the discrete GPU is active Libreoffice works; - If the discrete GPU is NOT active it crashes. @Michal Rezny It seemed to me too that it was working but there was a process (mbfloagent) which triggered the additional graphic which, in turn, allowed the LibreOffice execution. At the first reboot mbfloagent was gone and LO crash was back. Macbook pro mid 2010 nvidia 330M, LO 5.2.2.2, MACOS Sierra 10.12.1
(In reply to Luca Aluffi from comment #113) Clean restart, still works. Alas, I can't say which graphic card is currently active.
(In reply to Michal Rezny from comment #114) > (In reply to Luca Aluffi from comment #113) > > Clean restart, still works. Alas, I can't say which graphic card is > currently active. @Michal Rezny. You have two option to check the active card: 1) Use GfxCardStatus utility: https://gfx.io 2) Follow this steps: - Open System Profiler by choosing About this Mac from the Apple () menu, then click More Info. - Select the "Graphics/Displays" item in the Hardware section. - If you have two graphic cards you can see, in the detail section, which one is running the monitor. There are more detailed infos at this Apple's support link: https://support.apple.com/en-us/HT202053
(In reply to Luca Aluffi from comment #115) > (In reply to Michal Rezny from comment #114) > > (In reply to Luca Aluffi from comment #113) I am convinced, that iMac uses only dedicated graphics card. There is just one card mentioned in Profiler (AMD Radeon) and there is no "Requires High Perf Graphics" column in Activity Monitor (yes, not even between hidden columns)
It's weird and I have to report it again. I've fired up my test drive where there is macOS sierra 10.12.1 and, because a couple of months ago's experiments, a Libre Office Vanilla 5.2.1.2. The crash does not occurs, the GPU used is still the integrated one and not the discrete. What I would like to point again is that (in my case at least) the crash under Sierra started to occur AFTER the update of LIBREOFFICE and not after the operating system itself. Sequence has been: 1) El capitan + Libreoffice: everything fine and no discrete gpu triggering; 2) Sierra UPDATED and Libreoffice untouched: everything fine and no discrete gpu triggering; 3) Sierra untouched and Libreoffice UPDATE: crash started to occur. All crashes happened even restoring old libreoffice version from Time Machine or rsync backup. I am not fond with the install script process, but maybe it triggers something which ruins all.
Luca, is that observation is correct, it might be worth trying out some very old releases and see if they all lead to the crash: https://downloadarchive.documentfoundation.org/libreoffice/old/
I have a case of a simlilar looking freeze, although without any tweak to the color profile or any external vs internal video card. the backtrace was similar to the extent that it was once again a 'exception in malloc' double wammy kind of freeze.... and that one also got 'fixed' by upgrading to the latest Sierra. my previous repport of reproducing tweaking the color profile is also fixed by upgrading Sierra. I would be inclined to close as NOTOURBUG Norbert
(In reply to Dana Weick from comment #90) > In the meantime, for users that are experiencing the crash (likely on a 5k > iMac), please change your color profile (System Preferences > Display > > Color) to the Standard iMac Apple RGB profile for the time being." Hi. I can confirm that something like what you're suggesting fixed the problem. I'm on a MacBook Pro with 2 Thunderbolt Displays connected. I've got the f.lux utility running which happened to create its own f.lux profile. Changing the profile to Thunderbolt Display seems to have fixed the error. Now, setting it back to f.lux does not trigger the error again.
As Norbert says, it smells very badly of an Apple bug. Thanks for reporting though !
General consensus after discussion in QA IRC is, that 10.12.1 indeed fixes this specific problem. For any other crashes or issues please take the time to report a new bug. And NOTOURBUG is then indeed the correct status for this bug.
*** Bug 103690 has been marked as a duplicate of this bug. ***
*** Bug 103912 has been marked as a duplicate of this bug. ***