Bug 67688 - LibreOffice 4.1.0 crashes on startup
Summary: LibreOffice 4.1.0 crashes on startup
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: x86 (IA32) macOS (All)
: medium blocker
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-02 23:27 UTC by trg818
Modified: 2014-08-11 05:43 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Crash details OS X 10.7.5 (46.16 KB, text/plain)
2013-08-18 16:36 UTC, daniel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description trg818 2013-08-02 23:27:24 UTC
I just installed the most recent release of LibreOffice on my MacBook Pro (OS 10.5.8). Although the installation did not produce any error messages, the new version crashes on startup. I did not start with any specific document but just double-clicked the icon, so it should be unrelated to any specific document format.
The error messages listed by the crash reporter are as follows:
Process:         soffice [981]
Path:            /Applications/LibreOffice.app/Contents/MacOS/soffice
Identifier:      org.libreoffice.script
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  launchd [83]

Interval Since Last Report:          406 sec
Crashes Since Last Report:           1
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   1

Date/Time:       2013-08-03 01:25:04.323 +0200
OS Version:      Mac OS X 10.5.8 (9L30)
Report Version:  6
Anonymous UUID:  B13871CB-2A3C-4F84-8424-18C700E2435F

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0

Dyld Error Message:
  unknown required load command 0x80000022
Comment 1 Julien Nabet 2013-08-04 08:37:59 UTC
trg818:
- did you install any LO specific extension?
- do you reproduce this after having renamed your LO directory profile? (see https://wiki.documentfoundation.org/UserProfile)

If you still reproduce this, could you copy paste the whole error log in a file and attach the file to the bugtracker by using this link? https://bugs.freedesktop.org/attachment.cgi?bugid=67688&action=enter
Comment 2 trg818 2013-08-04 11:54:06 UTC
(In reply to comment #1)
> - did you install any LO specific extension?
I have a number of extensions installed, but...
> - do you reproduce this after having renamed your LO directory profile? (see
> https://wiki.documentfoundation.org/UserProfile)
... after having renamed the LO directory, I guess they should not be found anymore. Nonetheless, LO keeps crashing in the same way, so it doesn't seem to be an issue with the extensions.
> If you still reproduce this, could you copy paste the whole error log
The error log as posted in my initial message is complete, it is all I got.
Comment 3 Ben McGinnes 2013-08-07 07:30:31 UTC
The same thing occurred for me on the same version of OS X (10.5.8), but unfortunately the crash on launch was so fast it didn't even manage to generate the crash report in the console.  I have since rolled back to LO 4.0.4.2.

This isn't the first time this has happened with LibreOffice, the same thing occurred with one or more releases of the 3.x series on OS X 10.5.x.  Unfortunately I can't recall the precise version numbers or bug numbers relating to that issue or what the cause was ultimately identified as.  It was a while ago.
Comment 4 Julien Nabet 2013-08-14 23:33:59 UTC
Thorsten: reading about http://stackoverflow.com/questions/1440456/static-libraries-in-version-cross-compiled-program, could it be a building issue?
quotation:
"
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.

To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:

export MACOSX_DEPLOYMENT_TARGET=10.5
"
...
"
In addition to the compiler flags above, you should add:

-no_compact_linkedit

It is described here:

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html

where it says:

    Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information. 
"

(put it at NEW since 2 people describe the same problem)
Comment 5 daniel 2013-08-18 16:36:06 UTC
Created attachment 84204 [details]
Crash details OS X 10.7.5

I'm also seeing this behaviour with 4.1. I am running 4.04 with no obvious issues. I've attached a log of the 4.1 crashing on my 10.7.5 machine.

I've tried removing old folders, reinstallation any redownloading many times. I've also tried to disable all my startup items as suggested in this issue (https://bugs.freedesktop.org/show_bug.cgi?id=67326)

I have also created an issue on ask LO where I got an answer to look here for more information. http://ask.libreoffice.org/en/question/21537/libre-office-41-crash-each-startup-on-os-x/
Comment 6 Julien Nabet 2013-08-18 17:30:27 UTC
Daniel: did you install any specific fonts (I mean a font which isn't on MacOs out of the box)?
If yes, which one(s), do you have a link or could you attach it/them to the bugtracker?

Tor: crash details shows CoreText part:
0   com.apple.CoreFoundation      	0x97840921 CFStringGetLength + 17
1   com.apple.CoreFoundation      	0x97858cc3 CFStringCompareWithOptionsAndLocale + 35
2   com.apple.CoreFoundation      	0x97858c8c CFStringCompare + 60
3   com.apple.CoreText            	0x9c0850d9 TDescriptorSource::CompareFamilyNames(void const*, void const*, void*) + 181
4   com.apple.CoreText            	0x9c08ccc5 CompareLocalizedDescriptorsByTraitsAndPrecedence(void const*, void const*, void*, bool) + 270
5   com.apple.CoreText            	0x9c0b6f30 CompareDescriptorsByTraitsAndPrecedence(void const*, void const*, void*) + 39
I thought you might be interested in this so put you on cc.
Comment 7 daniel 2013-08-18 18:59:08 UTC
Julien

Yes. I do have some user fonts installed. I'm tried to attach a zip file with the font files to this issue but could not attach zip's. I posted a link at the bottom of this comment though. For a text overview, here they are;

font 3.ttf
font.ttf
MavenProLight-100.otf
MavenProLight-200.otf
MavenProLight-300.otf
Roboto-Black.ttf
Roboto-BlackItalic.ttf
Roboto-Bold.ttf
Roboto-BoldCondensed.ttf
Roboto-BoldCondensedItalic.ttf
Roboto-BoldItalic.ttf
Roboto-Condensed.ttf
Roboto-CondensedItalic.ttf
Roboto-Italic.ttf
Roboto-Light.ttf
Roboto-LightItalic.ttf
Roboto-Medium.ttf
Roboto-MediumItalic.ttf
Roboto-Regular.ttf
Roboto-Thin.ttf
Roboto-ThinItalic.ttf
Signika-Bold.otf
Signika-Light.otf
Signika-Regular.otf
Signika-Semibold.otf
SourceCodePro-Black.ttf
SourceCodePro-Bold.ttf
SourceCodePro-ExtraLight.ttf
SourceCodePro-Light.ttf
SourceCodePro-Regular.ttf
SourceCodePro-Semibold.ttf
Sreda.otf
Sreda.ttf

Fonts: https://docs.google.com/file/d/0B7YV9fBjVcOwcFk5QWFBYmpoczg/edit?usp=sharing
Comment 8 trg818 2013-08-18 19:12:41 UTC
For the record: I also have a couple of additional fonts installed on my machine, all of them in ~/Library/Fonts or subfolders of it. This is the list:
ArabDances.ttf
AfaratibnBlady.ttf
ALHAD___.TTF
ALHAMBRA.TTF
DALEK___.otf
DALEK___.ttf
RunishQuillMK-Medium.ttf
RunishQuillMK.ttf
PSAUDI5.TTF
RUNENG1.TTF
RUNENG2.TTF
RunishMK.ttf
VIKING-N.TTF
Yggdrasil.ttf

Can't remember where I got them, but it was some large open font repositories.
Comment 9 Julien Nabet 2013-08-18 19:54:03 UTC
Daniel: I retrieved the zip file and installed the fonts on my system (Linux Debian testing), I didn't reproduce the crash but perhaps it's a MacOs only bug.

trg818/Daniel: it could be useful you find at least 1 specific font in your list which triggers the bug by using a dichotomy method so we could focus on 1.

Alex/Roman: would one of you have some time to give it a try on Mac with Daniel's fonts?
Comment 10 daniel 2013-08-18 21:21:58 UTC
Julien: I tried removing all the fonts from my fontbook and reinstalled 4.1. The application still crashed at boot with pretty much the same crash log (some hex references to memory and pid's differ).
Comment 11 Julien Nabet 2013-08-19 05:51:40 UTC
(In reply to comment #10)
> Julien: I tried removing all the fonts from my fontbook and reinstalled 4.1.
> The application still crashed at boot with pretty much the same crash log
> (some hex references to memory and pid's differ).

If you're sure your removed all the "non out-of-the box" fonts + removed your LO directory profile too after  having reinstalled 4.1, I must recognize I've got no more idea for the moment :-(
Comment 12 Alex Thurgood 2013-08-23 13:16:46 UTC
Hi Julien,

Installed each font from the link individually on OSX 10.8.4 and started :

Version: 4.2.0.0.alpha0+
Build ID: 22d1beb78a475e4846af945afde1c4d6c263b5d6


64bit build from master each time.

No crash.

The OSX Font Installer utility did flag up that Sreda OTF and Sreda TTF conflicted because they contained duplicate character sets (Regular), but you can resolve this by deactivating one of them.


Alex
Comment 13 Ben McGinnes 2013-10-27 01:58:22 UTC
(In reply to comment #4)
> Thorsten: reading about
> http://stackoverflow.com/questions/1440456/static-libraries-in-version-cross-
> compiled-program, could it be a building issue?

It could be that, though it begs the question why 4.0.x is being built in a way that does not cause problems on OS X 10.5.8, but 4.1.x does cause problems.  My most recent test with 4.1.3.2 continues to crash on launch (with the same error as originally reported by trg818).  Unfortunately the guide to build from source explicitly says it is for OS X 10.6.x and above:

https://wiki.documentfoundation.org/Development/BuildingOnMac

Now if those instructions will also apply to 10.5.8 then I might give it a crack and try to build a binary for Leopard (with no guarantees that such a beast would work for anyone else).
Comment 14 Norbert Thiebaud 2013-10-27 04:34:14 UTC
(In reply to comment #13)
> 
> It could be that, though it begs the question why 4.0.x is being built in a
> way that does not cause problems on OS X 10.5.8, but 4.1.x does cause
> problems. 

4.0 was still supporting 10.4 SDK and higher, although we announced its deprecation back in December 2012.

for 4.1 we moved to a 10.6+ SDK... there is then no mystery that 10.5 runtime could cause trouble... as patch get in that take advantage of that...

more recently a patch was pushed to set the minimum version accordignly in the Info.plist, which should avoid a 'crash' as a symptom of using a binary that is not compatible with the runtime level...
It has not been backported though, so it will be for 4.2
Comment 15 Julien Nabet 2014-07-28 04:48:18 UTC
trg818/Daniel: any better with last stable LO version 4.2.5?
Comment 16 trg818 2014-08-10 23:22:40 UTC
(In reply to comment #15)
> trg818/Daniel: any better with last stable LO version 4.2.5?

Sorry for the delay in replying.
I can't test v.4.2.5, because it would require OS X 10.6 or newer, but I'm on 10.5.8.
Comment 17 Norbert Thiebaud 2014-08-11 05:43:12 UTC
"I can't test v.4.2.5, because it would require OS X 10.6 or newer, but I'm on 10.5.8."

That is the whole point. 4.1+ require 10.6 or newer.
The 'fix' was to set the plist properly so that it does not crash anymore if you try to run it on older version, but rather show a dialog indicating so.