256634 - TB07x crash searching mail messages [@ nsHTMLEditRules::WillInsertText]

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[Jay Patel [:jay]]

This is a topcrash for Thunderbird 0.7.x.  The comments vary, but a lot of them
mention running a search on mail messages:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsHTMLEditRules%3A%3AWillInsertText&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=

Here is one incident that involves search and has the
nsHTMLEditRules::WillInsertText stack signature:
Incident ID: 475893
Stack Signature	nsHTMLEditRules::WillInsertText 7c17dcdd
Product ID	Thunderbird10
Build ID	2004070722
Trigger Time	2004-08-03 15:00:49.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	thunderbird.exe + (003302df)
URL visited	
User Comments	When trying to use the search (ctrl+shift+f) first time goes fine,
but when I hit stop and search again, it crashes. (reproducable)
Since Last Crash	23 sec
Total Uptime	8357 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tbird-0.7.2/WINNT_5.0_Clobber/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp,
line 1374
Stack Trace 	
nsHTMLEditRules::WillInsertText 
[e:/builds/tbird-0.7.2/WINNT_5.0_Clobber/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp,
line 1374]


I have been able to reproduce, but with a different stack signature:
Incident ID: 634321
Stack Signature	0x00000000 8560629a
Email Address	[e-mail]
Product ID	Thunderbird10
Build ID	2004062616
Trigger Time	2004-08-23 13:46:41.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	searching mail
User Comments	2 "body contains" search... clicked stop/search a few times and boom!
Since Last Crash	28 sec
Total Uptime	748454 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x00000000

Still, this is a  major crash that a lot of people have been seeing, so marking
topcrash+.  This would be nice to get fixed for aviary1.0PR and if not by then,
 aviary1.0 for sure.

Comment 1

[Scott MacGregor]

this should really be in the thunderbird component so I actually see it. 

Comment 2

[Scott MacGregor]

Jay is it my imagination or are all of these talk reports for 0.7.

I don't think I see any that reference the 0.8 based builds judging by the build
ID. the latest one is August 8th for the build ID and I think hta was 0.7.2 or
0.7.3 respin date.

I'm hopefuly this may already be fixed given the lack of 0.8 based crash reports.

Comment 3

[Jay Patel [:jay]]

I logged this based on Thunderbird 0.7.x crashes that I found.  I have been
meaning to test this with the latest 0.8 builds.  I just did and I am no longer
crashing and I can't find any crashes in Talkback data after the 0.7.3 release
(8/3 builds)...so marking this fixed.

If I see this crash again in the Talkback data or if anyone is able to reproduce
it, we can reopen.

Comment 4

[Worcester12345]

(In reply to comment #3)
> I logged this based on Thunderbird 0.7.x crashes that I found.  I have been
> meaning to test this with the latest 0.8 builds.  I just did and I am no longer
> crashing and I can't find any crashes in Talkback data after the 0.7.3 release
> (8/3 builds)...so marking this fixed.
> 
> If I see this crash again in the Talkback data or if anyone is able to reproduce
> it, we can reopen.

This makes me wonder if there will be an interim Thunderbird release before the
RC release of Firefox, so as to get these fixes in, and to not overburden the
server when the time comes.

Comment 5

[Jay Patel [:jay]]

bigfoot:  This crash has been fixed since the release of 0.7.3.  It no longer
occurs in the latest nightlies for 0.8 branch builds...so this crash will be
gone in the next release/milestone. 

marking verified.

Comment 6

[Stefan Pietschmann]

looks like it has been fixed on the branch, so could somebody please add the 
fixed-aviary1.0 keyword?
(i know this is trivial but it would be useful for querying the overall number
of remaining bugs)

Comment 7

[Scott MacGregor]

bug fixes that are triaged into branch milestones (0.7, 0.8, 0.9, 1.0) will
never have the fixed-aviary1.0 tag on them. All of those milestones are branch
based releases and it's implicit that any bug with that milestone was fixed on
the 1.0 branch.