452025 - [10.4] Crash [@ TLine::CopyStringRange] or ObjC exception abort with weird characters in <title>

Status: RESOLVED WONTFIX

(Core :: Widget: Cocoa, defect)

Description

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a2pre) Gecko/20080824181037 Minefield/3.1a2pre

The characters in the testcases are:

U+2029  PARAGRAPH SEPARATOR          --   unusual whitespace character
U+0780  THAANA LETTER HAA            --   rtl
U+0341  COMBINING ACUTE TONE MARK    --   combining character

Comment 1

[Jesse Ruderman]

Attachment: testcase 1 (crashes Firefox when loaded)

[@ TLine::CopyStringRange], dereferencing 0xa1b1c1d3 (KERN_INVALID_ADDRESS)

Comment 2

[Jesse Ruderman]

Attachment: testcase 2 (crashes Firefox when loaded)

[@ nsObjCExceptionAbort]

The only difference between the testcases is that this one has an extra 'A' at the beginning of the title, before the unusual characters.

Comment 3

[Jesse Ruderman]

Attachment: stack trace for testcase 1

This stack trace is from the system crash reporter.  Surprisingly, gdb gives a less informative stack trace (missing function argument types).

Testcase 2 doesn't give a useful stack at all.  Firefox just aborts after saying

2008-08-24 20:24:20.866 firefox-bin[1777] Mozilla has caught an Obj-C exception [NSRangeException: NSMutableRLEArray objectAtIndex:effectiveRange:: Out of bounds]
2008-08-24 20:24:20.866 firefox-bin[1777] <No stack information available for Obj-C exception>

Comment 4

[Steven Michaud [:smichaud] (Retired)]

This is an Apple bug -- one specific to OS X 10.4.X.

I don't see any crashes on OS X 10.5.4, either in FF 3.0.1 or a recent
trunk nightly.

I do crash (with the same stack as reported in comment #3 when using
testcase1) on OS X 10.4.11.  But, though I don't crash in Safari, I
see several "out of bounds" exceptions in the system console.

The reason we crash while Safari doesn't has to do with how we fixed
bug 163260 -- we decided to (deliberately) crash the browser on every
Objective-C exception.

The original purpose of this was to prevent XPCOM code from getting
into an unstable (and potentially exploitable) state if Objective-C
exception handlers cause an XPCOM method to be exited without its
cleanup code having been called.  Because it was too difficult to
limit our use of these macros to XPCOM code, the mission got expanded
to include (in principle) any browser code that might make system
calls, and which therefore might trigger an Objective-C exception.

As far as I can tell, though, Safari never crashes on _any_
Objective-C exception (though it does crash on serious non-Objective-C
exceptions like dereferencing an invalid pointer, or one that points
to a deleted object).  See bug 441880 comment #1.

Because of the XPCOM worries outlined above, we can't follow the same
strategy as Safari.  But there will be some cases where an Objective-C
exception that we encounter is clearly non-fatal -- bug 442245 is an
example.  In these cases we may want to make an exception to our
"policy" and not crash.

We won't be able to decide whether or not to crash from the nature of
the exception -- clearly "out of bounds" exceptions should sometimes
be fatal (especially if they happen in XPCOM code).  But maybe we'll
be able to decide based upon where the exception occurs.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

John, do you have any idea how we might be able to work around the
(10.4.X-specific) Apple bug that triggers this crash?

Or in other words, have you seen problems like this before, and do you
have any idea how we might deal with them (short of messing with the
Objective-C exception handling code)?

Comment 6

[Jesse Ruderman]

Testcase 1 triggers a straight crash, so I don't think modifying the ObjC exception handling code would really help.  Why doesn't *that* crash happen in Safari?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> Testcase 1 triggers a straight crash

True enough.  So it seems that testcase1 triggers an additional
problem in FF 3 (whatever triggers the straight crash).  But if you
try testcase1 in Safari (on OS X 10.4.11) you'll see a bunch of "out
of bounds" exceptions logged to the system console.  So there's every
reason to believe that, if the straight crash were somehow avoided, FF
3 would do an Objective-C exception abort crash on the first of the
"out of bounds" exceptions.

Furthermore, the "additional problem" seems also to be an Apple bug --
it takes place entirely in Apple code.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

> Furthermore, the "additional problem" seems also to be an Apple bug --
> it takes place entirely in Apple code.

And happens only on OS X 10.4.X.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Attachment: Safari console log for testcase1 and testcase2

Comment 10

[Jesse Ruderman]

Can you do me a huge favor by creating a small Cocoa testcase and reporting this to Apple?

Comment 11

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #10)

I'm not sure I understand what you're asking.

Creating a separate Cocoa app that triggers this Apple bug would
probably _not_ be easy.

But it'd be very easy to send your testcase1 and testcase2 to Apple,
and report the errors they trigger in Safari (on OS X 10.4.11).

Comment 12

[Jesse Ruderman]

Ok, I guess I'll try reporting it to Apple and hope they don't ask me to make a "reduced testcase" ;)

Comment 13

[Jesse Ruderman]

rdar://6174697

Comment 14

[John Daggett (:jtd)]

No idea how to work around this.  The crash appears to be within 10.4 CoreText code which is pretty much a black box for us (CoreText is public only in 10.5).  One thought might be to run Safari with gmalloc enabled to see if some invalid access shows up earlier.  From the stack trace it seems like the stack is getting stomped on so that may not help.  It's also probably the reason we don't see valid stack traces in all cases.

Comment 15

[Jesse Ruderman]

rdar://6174697 has not attracted any comments from Apple :(

Comment 16

[Jesse Ruderman]

"After examining your report we do not see any actual security implications.  However, we do see that it can result in an unexpected application termination due to reading out of bounds.  We have changed the classification from 'Security' to 'Crash/Hang/Data Loss' to more accurately reflect this report."

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can we sanitize the characters we put in a window title to exclude U+2029 at least?

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Sounds reasonable to me.

But why are you suggesting we only sanitize U+2029?

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not, I said "at least" ... I think U+2029 is the culprit in this bug.

We should probably just strip based on gfxFontGroup::IsInvalidChar, except we should probably allow IS_BIDI_CONTROL_CHAR (we strip those from textruns because bidi processing happens at a higher level).

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We should probably allow ZWSP too.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

> I think U+2029 is the culprit in this bug

Why do you think so?  (This is what I really meant to ask.)

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I've noticed problems in the past with ATSUI when we mix hard line breaks like U+2029 with RTL. The bidi algorithm has to take account of those line breaks so it's not totally surprising. We don't want to get rid of actual readable characters, obviously, so it's the line breaks we should strip, they don't make any sense in titles anyway.

Comment 23

[Jesse Ruderman]

WFM on trunk, surprisingly.

Comment 24

[Jesse Ruderman]

Oh, this is a 10.4 only bug.

Comment 25

[Jesse Ruderman]

"Engineering believes this issue has been addressed in the Mac OS X 10.5.6 which is now available"

Sigh.