Created attachment 422897 [details] testcase (crashes Firefox when loaded) Crash [@ TAATKernEngine::KernIndexArray::ProcessForRun] -- touching the invalid address 0x190876a7. Like bug 541277, this is either a recent regression in Gecko or a regression from the recent Snow Leopard security update.
Gaaaaah, SOMETIMES crashes.
(In reply to comment #1) > Gaaaaah, SOMETIMES crashes. Sigh! Yes, I was able to repro this several times yesterday; today it's refusing to crash for me. This looks to me like an Apple bug rather than a Gecko one, but it's going to be difficult to track down or provide a useful report unless we can come up with a consistently-crashing testcase. :(
Whiteboard: [sg:critical?] → [sg:vector-critical (Apple)]
The crash happens reliably enough on Firefox trunk, both opt and debug. bp-a538750c-b899-4a4d-bdcb-8bdd42100322 (opt)
Only crashes on Mac OS X 10.6, not on Mac OS X 10.5.
Reported to Apple. rdar://7781036
Whiteboard: [sg:vector-critical (Apple)] → [sg:vector-critical (Apple)] rdar://7781036
Apple says: --- The crash appears to be an out-of-bounds memory read. Without further information showing that it can lead to arbitrary code execution or other unauthorized access, it appears that this issue is a denial of service that results in the unexpected termination of Firefox, but not of the host operating system or a system service. For our internal tracking purposes, this will be classified as a "Crash / Hang" issue. Although we do not see additional security concerns, we do consider this to be an important issue, and are working with the engineering team to address it. If you have reason to believe that the issue has ramifications beyond terminating Firefox (such as terminating the operation of the host operating system or system service, or executing arbitrary code), we would appreciate the steps to reproduce this, or crash logs from when you observed it. ---
Whiteboard: [sg:vector-critical (Apple)] rdar://7781036 → [sg:vector-dos (Apple)] rdar://7781036
You gave them that data, I assume?
I don't have reason to believe that this is something other than an OOB read, or that the OOB read leads to something worse. Do you? An OOB read is consistent with "sometimes crashes" in that an OOB read can be a crash depending on the position of a page boundary. But it's hard for me to explain the bad address ending in 0x6a7 rather than something that looks like it's next to a page boundary.
I reproduced this today with a debug build, it looks like an odd face of Skia is involved. Skia is an old GX font which supports weight/width variations. Under 10.5 a single face "Regular" shows up in FontBook but in 10.6 a whole set of faces is available, I have a feeling they're synthesizing faces in the font system somewhere. <html><body><span>‮</span><span>⁽浳</span></body></html> Times is matched for 202E and then the Skia face is matched for 207D 6D73. Using the Postscript name of the face in Safari, I couldn't reproduce the crash. I'll do some more testing when I fix up my 10.6 partition, somehow this crash caused the partition to get hosed, *sigh*.
(In reply to comment #10) > I reproduced this today with a debug build, it looks like an odd face of Skia > is involved. Skia is an old GX font which supports weight/width variations. > Under 10.5 a single face "Regular" shows up in FontBook but in 10.6 a whole set > of faces is available, I have a feeling they're synthesizing faces in the font > system somewhere. That means they're exposing the variation "instances" as individual faces. This must be new in 10.6; until now, the only way to access those has been via specific variation-font APIs. Remember bug 554820, where we saw that Snow Leopard is returning synthetic "enhanced" font tables rather than the original data from the font file, in certain circumstances? Sounds like something vaguely similar is happening here, except this time it's to do with available faces. If they're exposing the variation instances of Skia as individual faces, then they must be synthesizing modified versions of associated tables to go with them, I guess. > the Skia face is matched for 207D 6D73 That makes no sense. Yes, Skia supports U+207D, but it doesn't have U+6D73. So this implies that something's going wrong when we check the cmap - possibly related to the fake-table synthesis they're doing in ATS. And I've seen crashes within Core Text previously when an unsupported character is present (hence http://mxr.mozilla.org/mozilla1.9.2/source/gfx/thebes/src/gfxCoreTextFonts.cpp#863 in the old Core Text code). It's apparently not OK to ask Core Text to shape text with a font that doesn't support the characters that are actually present. > somehow this crash > caused the partition to get hosed Thanks for the warning, I'll be sure to do a fresh backup before I try anything here!
Crash Signature: [@ TAATKernEngine::KernIndexArray::ProcessForRun]
The testcase doesn't crash in Firefox trunk for me on OS X 10.6.8, even with gfx.font_rendering.harfbuzz.scripts set to 0, and it also doesn't crash for me on 3.6.24. I suspect this has been fixed in OS X.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.