New crash [@ GenerateFlatTextContent] in Firefox 3.6b3 and [@ nsQueryContentEventHandler::GenerateFlatTextContent(nsIRange*, nsString&) ] on 1.9.0

RESOLVED FIXED in mozilla1.9.3a1

Status

()

defect
--
critical
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: jst, Assigned: m_kato)

Tracking

({crash, regression})

1.9.2 Branch
mozilla1.9.3a1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(status1.9.2 beta5-fixed, status1.9.1 .8-fixed)

Details

(crash signature, )

Attachments

(2 attachments)

There's a new crash in Firefox 3.6b3 with the signature "GenerateFlatTextContent" in Firefox 3.6b3 that hasn't been seen in any of the versions 3\.5.*.
Posted patch patch v1Splinter Review
Attachment #414456 - Flags: review?(Olli.Pettay)
Keywords: crash
Summary: New crash [@GenerateFlatTextContent] in Firefox 3.6b3 → New crash [@ GenerateFlatTextContent] in Firefox 3.6b3
UUID	9e9cf339-8a74-490b-9558-c98972091122
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
User Comments	갑작스러운 프로그램 종료
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsQueryContentEventHandler::GenerateFlatTextContent 	content/events/src/nsQueryContentEventHandler.cpp:201
1 	xul.dll 	nsQueryContentEventHandler::GetFlatTextOffsetOfRange 	content/events/src/nsQueryContentEventHandler.cpp:549
2 	xul.dll 	nsQueryContentEventHandler::OnQuerySelectedText 	content/events/src/nsQueryContentEventHandler.cpp:381

UUID	a9164e02-a07e-4db3-ab77-6ac3e2091124
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
User Comments	fuzakennna
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsQueryContentEventHandler::GenerateFlatTextContent 	content/events/src/nsQueryContentEventHandler.cpp:201
1 	xul.dll 	CompositeDataSourceImpl::Unassert 	rdf/base/src/nsCompositeDataSource.cpp:963
Blocks: 348341
Attachment #414456 - Flags: review?(Olli.Pettay) → review+
Assignee: Olli.Pettay → m_kato
Attachment #414456 - Flags: approval1.9.2?
Looks like mFirstSelectedRange's can be null. If so, the endNode might be null because startNode null checking was done in nsContentEventHandler::Init. So, maybe, we should check the endNode in Init() too.

However, I wonder why they can be null...
Comment on attachment 414456 [details] [diff] [review]
patch v1

a=jst
Attachment #414456 - Flags: approval1.9.2? → approval1.9.2+
landed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/15c46082297d
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Kato-san, shouldn't we land this to 1.9.1 branch too?

# Note that nsContentEventHandler was renamed after 1.9.1, the old name is nsQueryContentEventHandler.
We should need this since this occurs on 3.5.5 (http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.5.5&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=&do_query=1).

Also, after fixing this on 3.6 and m-c, there is no report for this crash.
Attachment #416602 - Flags: review?(Olli.Pettay)
Comment on attachment 416602 [details] [diff] [review]
patch for 1.9.1 tree

This is for 1.9.1 tree.  Many same crashes are reported on 3.5.5
Attachment #416602 - Flags: review?(Olli.Pettay) → review+
Comment on attachment 416602 [details] [diff] [review]
patch for 1.9.1 tree

Many CJK users are reporting this crash when using IME.
Attachment #416602 - Flags: approval1.9.1.7?
Comment on attachment 416602 [details] [diff] [review]
patch for 1.9.1 tree

Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #416602 - Flags: approval1.9.1.8? → approval1.9.1.8+
Crash reporter doesn't list any crashes for 3.5.8pre builds anymore. But to make sure that it has been fixed I would like to see a testcase. Makato, could you give us some steps which can be used to put Firefox in that crashing situation?
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=6610

This bug report is similar. Kato-san, can you use the testcase on branch? (The testcases don't work fine on trunk due to bug 125282.)
(In reply to comment #15)
> Crash reporter doesn't list any crashes for 3.5.8pre builds anymore. But to
> make sure that it has been fixed I would like to see a testcase. Makato, could
> you give us some steps which can be used to put Firefox in that crashing
> situation?

I don't know repro step.  This bug is from crash-stat data.

(In reply to comment #16)

> This bug report is similar. Kato-san, can you use the testcase on branch?
> (The testcases don't work fine on trunk due to bug 125282.)

Thank you, Nakano-san.  But, although I try using test case on Japanese community server, I cannot reproduce this issue on Firefox 3.5.7 + Windows (IME2003) and Mac OS X (Kotoeri).
(In reply to comment #18)
> Masayuki, Makoto, is this bug the same crash as these:
> https://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&date=2010-09-07%2020%3A00%3A00&signature=nsQueryContentEventHandler%3A%3AGenerateFlatTextContent(nsIRange*%2C%20nsString%26)&version=Camino%3A2.0.4
> ? It looks like it to me.
> 
> If so, I'd like to see about taking this on 1.9.0, since Camino still is
> releasing from there.

startNode and endNode seem to be NULL.  I believe that this is same issue.  So, this will be fixed by porting to 1.9.0 tree.
Comment on attachment 416602 [details] [diff] [review]
patch for 1.9.1 tree

(In reply to comment #19)
> startNode and endNode seem to be NULL.  I believe that this is same issue.  So,
> this will be fixed by porting to 1.9.0 tree.

Thanks!  The 1.9.1 patch applies and builds on 1.9.0, so I'll just request approval1.9.0.next on it.

(I haven't found any STR or testcase in the comments from our crashes, either, so we'll just have to trust it works as well on 1.9.0 as on 1.9.1/1.9.2 :) )
Attachment #416602 - Flags: approval1.9.0.next?
Summary: New crash [@ GenerateFlatTextContent] in Firefox 3.6b3 → New crash [@ GenerateFlatTextContent] in Firefox 3.6b3 and [@ nsQueryContentEventHandler::GenerateFlatTextContent(nsIRange*, nsString&) ] on 1.9.0
Crash Signature: [@ GenerateFlatTextContent] [@ nsQueryContentEventHandler::GenerateFlatTextContent(nsIRange*, nsString&) ]
You need to log in before you can comment on or make changes to this bug.