open text document; scroll through the font drop-down to see this font - bang. Font attached.
Created attachment 46503 [details] font that crashes the Mac build
Fontforge error message: invalid PostScript font name, see the attached screenshot. Corrupted font?
Created attachment 46506 [details] Fontforge error message
Created attachment 46554 [details] backtrace backtrace as per instructions Navigate to wherever 'soffice.bin' lives in your install. gdb --args ./soffice.bin --calc run <reproduce crash> backtrace
Hey Peter - thanks for that. Unfortunately we really need this piece compiled with debuginfo: #11 0x97094851 in ATSUGetGlyphBounds () #12 0x01a5192f in component_getFactory () #13 0x01a5168d in component_getFactory () #14 0x017f01ff in ImplFontData::ImplFontData () #15 0x017f2184 in OutputDevice::GetTextArray () the component_getFactory pieces are bogus. Can you source the *Env.Set.sh file into your shell: cd vcl/ ; rm -Rf *li.pro; and run 'build debug=true' then if you copy the libraries from the *li.pro/lib directory into your install and re-run gdb we should get an even more interesting trace. Thanks !
Font is FreeSans.ttf the same font breaks icu as well. https://bugzilla.redhat.com/show_bug.cgi?id=674328 http://bugs.icu-project.org/trac/ticket/8320 its just that I patched our icu to not break on it
i.e. ATSUGetGlyphBounds is an apple-provided api. http://bugzilla.neooffice.org/bug.php?op=show&bugid=707 is another manifestation of this. If we black listed these fonts in the aqua-specific GetDevFontAttributes then they wouldn't get added to our known font list http://opengrok.libreoffice.org/xref/core/vcl/aqua/source/gdi/salatsuifontutils.cxx#378 looks a good place, e.g. check for the name of the font, ideally with a check for the version of the font so later possibly fixed one would be allowed. I don't have a mac, so can't fix it myself.
black-listing it would be a relatively easy hack for someone with a bit of MacOSX experience I guess
Caolan: would http://cgit.freedesktop.org/libreoffice/core/commit/?id=90496967fe7ddb8a616dce8c70013fa4450c5983 fix it by any chance or is it completely unrelated?
I think its unlikely to have an effect, given that the reported bt is in ATSUGetGlyphBounds. I still think this is likely an easy bug to fix, or cook up a FreeSerif version dependent check, for someone with a Mac though.
(In reply to comment #10) > I think its unlikely to have an effect, given that the reported bt is in > ATSUGetGlyphBounds. I still think this is likely an easy bug to fix, or cook up > a FreeSerif version dependent check, for someone with a Mac though. I'm trying to understand your ICU patch.. no quite there yet :-) wouldn't it be more similar in spirit to deal with that in AquaSalGraphics::GetRawFontData() there are few sanity check on the font table there... maybe one more (that would avoid a ugly hack hard-coding a font name... which is going to get in a way if/when that font is fixed)
The crash is in ATSUGetGlyphBounds, right ?, i.e. comment #5, so doesn't that mean it doesn't matter what you do in GetRawFontData because ATSUGetGlyphBounds parses the font file itself ?, or is there some callback somewhere that reenters back to us. re the black-list suggestion the idea would be to hook it off a specific name+version if all else fails.
Hi, Please let me know if I can be of assistance. I know a lot about the innards of FreeSans. It might be helpful to sort out, what of the many features in the font triggers the software bug. (These fonts are just data files: a software crash should not be blamed on data. It is to be viewed as a software bug.) Unfortunately I don't have a Mac handy, or I would have tried this myself. Cheers!
I still maintain that a font is data, and it shouldn't crash software, no matter what, but... The font in the attachment is very messed up. It has obviously corrupted TTF strings (the ones that show up in Chinese). It looks like it may have been a very old version of FreeSans, the last date in it is 2003. I would really like to know where this thing came from. The earliest copy of FreeSans on the official site is from 2005, and I can assert that by 2008, there was no 2003 version posted on the site. Does this bug occur with any non-ancient version of FreeSans? The latest is dated 20120503, and may be downloaded at http://ftp.gnu.org/gnu/freefont/ It would make me feel better, if you could change the title of this report to indicate that the "FreeSans" it refers to is not a recent release. Thanks!
I am a Mac programmer fairly knowledgeable about the text APIs. I am downloading the LibreOffice source right now… I will test with a modern release of FreeSans.
Just to get it to configure, I had to do: $ sudo xcode-select /Applications/Xcode.app $ sudo mv /opt /opt-disabled $ ./autogen.sh --with-max-jobs=8 --with-num-cpus=8 --enable-debug --with-macosx-sdk=10.7 --without-doxygen That took about half an hour to figure out.
Nicholas: Out of interest, what did xcode-select -print-path clang print before you used that xcode-select command? (I honestly don't know, I am not suspecting you of having any kind of weird setup or something. We don't have the possibility to test all possible combinations of software versions and whatnot. When I added that use of xcode-select -print-path to configure.in, I assumed it would print out something sensible (i.e. the path to the tool in the latest installed Xcode, or something) without having been run to select an Xcode installation by the user, but maybe that is not the case then?) Also, is the --with-macosx-sdk option really necessary, i.e. what happens if you leave that out? (Or is it just that you prefer to build against the 10.7 SDK, as opposed to the 10.6 SDK which I assume is what you would get otherwise?) (FYI: You don't (currently) "win" anything, as far as I know, by building against the 10.7 SDK. LibreOffice uses only APIs present already in the 10.4 SDK... And some that were obsolete already in 10.4, eek! Yes, this is kinda sad, we don't even (optionally) (at run-time, or compile-time) try to use any newer APIs for newer style of some functionality. But hopefully you can be the Mac-based volunteer developer we have long been waiting for, who eagerly can help us modernize our Mac code!;) (If you are into text APIs, you might want to help in figuring out what goes wrong in a LibreOffice built with the --enable-coretext configure option. It builds fine, and starts, but then after one just types a bit into Writer, it gets into a loop and does nothing.)
(He replied on IRC that xcode-select was previously set to point to an older version of Xcode.)
Whoops, freeing this bug for easyhack takers.
Hi, Cannot reproduce using latest LibreOffice from git, main branch. Compiling on OSX 10.8.4, using with XCode 4.3 and 5 (beta1) installed - not sure which libraries it's linking against. Imported the font attached into FontBook on OSX. OSX told me that it was a broken font and that "major system instability might result". As this is what I want, I said OK. Then I set text in LibreOffice to FreeSans. Did not crash - so cannot reproduce in Version: 4.2.0.0.alpha0+ build id ea4fc480c7317b16f4abbafacda3872bb7413357. Tim
Since the crash was in ATSUI and we have now moved to Core Text by default, I’m closing this (it wasn’t our bug from the start anyway).
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp SkillDebug TopicDebug) [NinjaEdit]