Apache OpenOffice (AOO) Bugzilla – Issue 71096
X11 1.1.2 d/l via System Update breaks OpenOffice
Last modified: 2006-11-15 22:56:28 UTC
My System automatically downloaded and installed Apple X11 1.1.2 an hour ago. It broke OpenOffice.org. I get the splash screen, and the progress bar goes a third of the way across, but then it dies. I'm running OS X 10.4.8 on an iMac Intel Core Duo with 1GB of RAM. It was working perfectly right before this happened, like within an hour. Now, the program is completely inaccessible, which is very bad for me, as all my work files are in .odt and I can't get them! Tried uninstalling & reinstalling. Restarted the system. Fixed permissions with Disk Utility. Tried defaults write com.apple.x11 enable_stereo -bool true as suggested by update, didn't work, so deleted the key. Deleted my user's preferences folder, and restarted program, but didn't work. Tried "manually" launching by bypassing droplet in OO.org folder and using Terminal, but didn't work. Reported on Apple's website, but no replies yet. Please help!
same here - attaching crash log
Created attachment 40237 [details] crash log X11 updated
Tried restarting the computer - no help. ktrace attached.
Created attachment 40238 [details] ktrace starting /Application.../soffice
made a fresh installation of OOo and also tried accept and not accept options to use fonts from the system. no help.
cc pjanik
hdu: do you have any idea who can divide by zero in GetTTGlobalFontInfo?
@pjanik: this usually happens when a font doesn't have some values where psprint expects them. Please provide the problematic font or at least the font name. You'll find the font name in frame 2 of the stack you provided as argument to psp::PrintFontManager::analyzeFontFile()
Created attachment 40245 [details] new trace
I do not have an issue, so it would appear that a font issue could be the problem. If you wish me to test any font files, please let me know.
I moved each Vera font out of the way one by one in alphabetical sequence, and tested each time. After the 5th try things work again. jim-watsons-computer:/usr/X11R6/lib/X11/fonts/TTF jim$ ls *save Vera.ttf.save VeraBd.ttf.save VeraSeBd.ttf.save VeraBI.ttf.save VeraSe.ttf.save
Any one of the five listed fonts is sufficient to cause the crash. The trace shows only the Vera fonts have "too big table offset", but the attached trace from the correct working version shows this message is not fatal.
Created attachment 40249 [details] working version with fonts moved away
Failure trace is attached, showing vera fonts with "too big table offset" but some of these fonts are not moved way in the working version... In other words, some of Vera fonts which have "too big table offset" do not need to be moved away.
Created attachment 40250 [details] showing ssome vera fonts whicch are not removeed
info from hdu: In the font file you sent me some bytes had the value 0x0a were 0x0d should have been and some 0x0d+0x0a combos became 0x0a. Some program obviously treated the truetype file as text and worked really hard to "get the line end markers right". Well, this is not a good idea... Don't mess with binary files ;-)
Workaround: although not all Vera fonts are bad, it will be simpler for users to move all the Vera fonts away. To avoid more confusion I suggest use exactly the same as here: http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&t=3414&start=0&postdays=0&postorder=asc&highlight= sudo mkdir -p /usr/X11R6/lib/X11/fonts/TTF.bad sudo mv /usr/X11R6/lib/X11/fonts/TTF/Vera*.ttf /usr/X11R6/lib/X11/fonts/TTF.bad The -p means "no error if existing, make parent directories as needed" All reports I have seen so far are Mac Intel.
*** Issue 71135 has been marked as a duplicate of this issue. ***
Why the workaround works - the system Vera fonts are causing the crash, but it appears OOo is running with the older Vera fonts in application folder .../MacOS/share/fonts/truetype.
I can now confirm a crash with the official release, but not with own builds that have been made with the oobuildbot. I think we need to check the configure options that have been used to see if there is a difference there, or a change in some other part of the source code.
From: prabhaka@apple.com Subject: Re: X11 Update Font Issues Date: 4 November 2006 5:06:48 AM To: x11-users@lists.apple.com Hi all, Yes, we were made aware of these concerns yesterday. We're looking into it. Stay tuned. -- Ernie P.
Shaun McDonald reported on IRC that the crash is not seen in the 2.1M1 build by buildbot. I fetched the install set from the buildbot and confirmed it would not crash, while the 680m5 (maho) and m186 (my build) did crash. I did cvs update to my last build m186 module psprint and copied psprint/unxmacxi.pro/lib/* into the maho 680m5. At m187 the crash stopped, further tests show to prevent the crash in 680m5 it is sufficient to update psprint/source/fontsubset/sft.c to -r 1.39 dated 13 Oct 2006. After that, a fresh installation of 680m5 will refuse to crash, until I removed the users ~/Library/Application Support/OpenOffice 2.0
correction - the relevant update for fix was m188, not 187
*** Issue 71166 has been marked as a duplicate of this issue. ***
*** Issue 71193 has been marked as a duplicate of this issue. ***
I also found that removing the Vera fonts works. However, thousands of users are going to have this problem. Is there going to be a new build published to fix this issue at the root cause? (that is, doesn't crash when it encounters non-standard data?) Hugh
Hi, I've been making my own builds of tons of open source projects (mainly to get a/v apps such as mplayer/ffmpeg working with as wide support as possible) since the Jaguar days. I didn't have the trouble with fonts as noted here after upgrading Apple's X11, i.e. OOo-2.0.4-680m186 is working just fine for me. The current NeoOffice-2.0b3+patch7 is working fine, too. I'd like to explain why, please, to get it logged for reference and clues. (I'll try to get this posted to Apple's maillists, too.) I have been noticing that just about every open source project that Apple provides is quite back-level, including their new X11.dmg itself (it is still X11-4.4.0, while 4.6.0 has been release since early Summer 2006). Other "conglomerations" such as OOo and Mozilla are usually internally using back-level versions of other projects (as internal components). When rebuilding these components to use latest versions myself, I try not to overlay Apple's binaries in /usr, but instead install into /usr/local if at all possible. Then set the various xPATHs etc. to find them first (including DYLD_LIBRARY_PATH, which btw absolutely requires a case-sensitive filesystem so that Apple's purposely-misspelled frameworks libGIF etc. can still be found by the GUI subsystem, because libGIF etc. do not have the expected modules that are in the regular libgif etc. ... I hope is clear without going into more trouble to explain ;) ). Of course to get the GUI subsystem itself (Finder etc.) to use these xPATHs, one must create/edit ~/.MacOSX/environment.plist with appropriate data (way too o.t. for this bugreport). Then apps like NeoOffice will follow suit, too. The first thing I _always_ do with Apple's X11 is rebuild freetype and fontconfig with the latest versions available (freetype-2.21 and fontconfig-2.3.95 AFAIK as I write this). Also, I tell fontconfig to configure itself this way: ./configure \ --with-add-fonts="\ /System/Library/Fonts,\ /Library/Fonts,\ /usr/local/etc/fonts,\ /usr/local/share/mplayer/font,\ /usr/local/share/vlc/skins2/fonts,\ /usr/X11R6/lib/X11/fonts/100dpi,\ /usr/X11R6/lib/X11/fonts/75dpi,\ /usr/X11R6/lib/X11/fonts/CID,\ /usr/X11R6/lib/X11/fonts/cyrillic,\ /usr/X11R6/lib/X11/fonts/local,\ /usr/X11R6/lib/X11/fonts/misc,\ /usr/X11R6/lib/X11/fonts/Speedo,\ /usr/X11R6/lib/X11/fonts/TTF,\ /usr/X11R6/lib/X11/fonts/Type1\ " When building fontconfig on Terminal (without X11 running), you want to export DISPLAY=":0.0" as a dummy value so that its installer tools (esp. its font indexer) will work. When building freetype, I did the header hacks to enable "proprietary" Truetype hints and other stuff, which I presume we as Mac users have an official license to use since we bought Apple's hardware & software in the first place. ;) But freetype must be configured to install into /usr/X11R6 to overwrite Apple's binaries (it's a bit too complex to install freetype in /usr/local and do symlinks from the X11 subdirs). Actually for my own test system here, I actually build & install freetype _twice_, once for the X11 subsystem and again to get it into /usr/local for all other apps (I don't think fontconfig needs to be done this way, /usr/local is sufficient for it with appropriate xPATHs set). It might be the additional fontconfig fontpaths spec that is bypassing the cruddy fonts in the X11 subdirs on my system here. I do have a set of Vera*.ttf files in /Library/Fonts dated in 2004 (M$ didn't provide Finder-viewable version strings for them). I'm not sure if fontconfig actually sets the "font search path order" via that configure parm, either. I've also put a symlink: /usr/X11R6/bin/soffice->/Applications/OpenOffice.org/OpenOffice.org\ 2.0.app/Contents/MacOS/program/soffice and simply type 'soffice' in the xterm that Apple's X11 starts-up. I have /etc/bashrc & .profile etc. to pull in the xPATHx settings etc., but this might not be sufficient to ensure soffice uses _my_ newer builds of those libs. The final test would be to build X11-4.6.0 but I'm having a lot of trouble doing so, even though they've stated most Darwin build problems should be fixed in it already. I'm certainly trying to remove its wanting to build its own internal (backlevel) copies of freetype etc. etc. etc. -- and I wish other projects such as OOo and Mozilla will allow builders to do that, too (tons of bloat with the way things are currently done for OSX apps). If these "conglomeration" projects won't allow builders to use external freetype etc., then I really do hope we all can get these projects caught-up to latest stable releases in the internal components they use. With my being involved with computers since the 1970s, that's the main thing I've learned in all these years. ;) Thank you for letting me chime-in about this.
*** Issue 71207 has been marked as a duplicate of this issue. ***
See http://porting.openoffice.org/mac/news/news2006.html#20061105 for workaround.
Another workaround suggested on Apple discussion http://discussions.apple.com/thread.jspa?threadID=716448&tstart=0 is to kill the X11 update 2006 by typing sudo rm -R /usr/X11R6 /etc/X11 /Applications/Utilities/X11.app /Library/Receipts/X11* Which would be a better solution? Kill the bad font? or Kill the update?
The "workaround" by myu is nonsense. It removes not only X11, but other apps/files stored in that directory. DO NOT USE IT.
Thanks pjanik, Glad I asked before trying. I'll go kill the font then rather than re-installing X11.
*** Issue 71326 has been marked as a duplicate of this issue. ***
System update to X11 1.1.3 from Apple appears to resolve this issue on my iMac. It specifically states that it addresses font issues, so it seems all is right with the world now.
as reported by breaky and also here OOo2.0.4 (680_m5) is working with X11 1.1.3 so I will mark this issue as "fixed" because (a) the fonts are fixed and (b) OOo is already fixed in builds from m188.
yes, thus closing. Nice episode in Mac porting team. Thanks Apple for their cooperation on this issue.
Just to respond to an email from Jim Watson, I saw the same thing you had. I did not re-install anything (X11 or OOo). I just let System Update do its thing with 1.1.3, and everything was fine.