Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050908 Firefox/1.6a1 TB9203727M
Assuming this crash is due to calling GetType on a deleted frame, bz thinks this isn't an exploitable crash in opt builds, because frames are arena-allocated and the arena isn't recycled until the page goes away.
Created attachment 195691 [details] [diff] [review] fix Move the null checks inside functions. This way we can take away the early returns in the other codes and give them a chance to continue updating the remaing states of the frames, even when the underlying markup is invalid.
Created attachment 195769 [details] Testcase2 With this testcase, I get approximately crashes with the same stacktrace: TB9278959K TB9278831M So this is probably also fixed with the patch.
Checked in the trunk yesterday. So today's builds now have the fix.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
OS: MacOS X → All
Hardware: Macintosh → All
Resolution: --- → FIXED
Yup, verified with 2005-09-12 build.
Status: RESOLVED → VERIFIED
Attachment #195691 - Flags: approval1.8b5? → approval1.8b5+
Checked in the 1.8 branch.
v.fixed on branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050928 Firefox/1.4, testcases don't crash and no crashes since 9/12 in Talkback data.
Keywords: fixed1.8 → verified1.8
Crashtests checked in.
Crash Signature: [@ nsMathMLContainerFrame::GetType]
You need to log in before you can comment on or make changes to this bug.