Bug 37035 - Mac crash when using FreeSans 1.27 (circa 2003)
Summary: Mac crash when using FreeSans 1.27 (circa 2003)
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.4.0 Beta4
Hardware: Other macOS (All)
: medium critical
Assignee: Tim Wright
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp, skillDebug, topicDebug
Depends on:
Blocks:
 
Reported: 2011-05-09 13:03 UTC by Michael Meeks
Modified: 2015-12-15 23:24 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
font that crashes the Mac build (254.68 KB, application/x-font-ttf)
2011-05-09 13:03 UTC, Michael Meeks
Details
Fontforge error message (17.57 KB, image/png)
2011-05-09 14:25 UTC, László Németh
Details
backtrace (5.50 KB, text/plain)
2011-05-10 08:44 UTC, Peter Teeson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2011-05-09 13:03:16 UTC
open text document; scroll through the font drop-down to see this font - bang.
Font attached.
Comment 1 Michael Meeks 2011-05-09 13:03:43 UTC
Created attachment 46503 [details]
font that crashes the Mac build
Comment 2 László Németh 2011-05-09 14:24:23 UTC
Fontforge error message: invalid PostScript font name, see the attached screenshot. Corrupted font?
Comment 3 László Németh 2011-05-09 14:25:24 UTC
Created attachment 46506 [details]
Fontforge error message
Comment 4 Peter Teeson 2011-05-10 08:44:34 UTC
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
Comment 5 Michael Meeks 2011-05-10 08:54:55 UTC
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 !
Comment 6 Caolán McNamara 2011-08-25 06:40:27 UTC
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
Comment 7 Caolán McNamara 2011-08-25 06:54:57 UTC
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.
Comment 8 Caolán McNamara 2011-08-25 07:06:04 UTC
black-listing it would be a relatively easy hack for someone with a bit of MacOSX experience I guess
Comment 9 Julien Nabet 2012-08-18 18:21:19 UTC
Caolan: would http://cgit.freedesktop.org/libreoffice/core/commit/?id=90496967fe7ddb8a616dce8c70013fa4450c5983 fix it by any chance or is it completely unrelated?
Comment 10 Caolán McNamara 2012-08-19 19:33:37 UTC
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.
Comment 11 Norbert Thiebaud 2012-08-21 04:03:41 UTC
(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)
Comment 12 Caolán McNamara 2012-08-22 11:41:36 UTC
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.
Comment 13 Steve White 2012-08-22 17:09:32 UTC
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!
Comment 14 Steve White 2012-08-22 17:25:42 UTC
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!
Comment 15 Nicholas Shanks 2012-08-22 18:11:28 UTC
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.
Comment 16 Nicholas Shanks 2012-08-22 19:45:29 UTC
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.
Comment 17 Don't use this account, use tml@iki.fi 2012-08-23 19:46:26 UTC
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.)
Comment 18 Don't use this account, use tml@iki.fi 2012-08-23 20:18:12 UTC
(He replied on IRC that xcode-select was previously set to point to an older version of Xcode.)
Comment 19 Thorsten Behrens (allotropia) 2013-02-20 08:53:50 UTC
Whoops, freeing this bug for easyhack takers.
Comment 20 Tim Wright 2013-08-11 03:57:31 UTC
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
Comment 21 Khaled Hosny 2013-08-11 08:10:33 UTC
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).
Comment 22 Robinson Tryon (qubit) 2015-12-15 23:24:10 UTC
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp SkillDebug TopicDebug)
[NinjaEdit]