crash during spell check? [@ nsTextServicesDocument::IsBlockNode(nsIContent*)] Crash Address 0x8 in most cases rarely seen in FF (avg 2 per month) bp-ceff975e-8aac-4bdc-af7f-524422091020 bp-a5286843-5a4a-4c5c-a8ac-f92022090508 Ran spell checker and when I chose to replace a word, the carsh occurred. 0 thunderbird.exe nsTextServicesDocument::IsBlockNode editor/txtsvc/src/nsTextServicesDocument.cpp:3095 1 thunderbird.exe nsTextServicesDocument::FirstTextNodeInNextBlock editor/txtsvc/src/nsTextServicesDocument.cpp:4263 2 thunderbird.exe nsTextServicesDocument::GetFirstTextNodeInNextBlock editor/txtsvc/src/nsTextServicesDocument.cpp:4325 3 thunderbird.exe nsTextServicesDocument::FirstBlock editor/txtsvc/src/nsTextServicesDocument.cpp:615 4 thunderbird.exe mozSpellChecker::Replace extensions/spellcheck/src/mozSpellChecker.cpp:223 5 thunderbird.exe nsEditorSpellCheck::ReplaceWord editor/composer/src/nsEditorSpellCheck.cpp:308 6 xpcom_core.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101 7 thunderbird.exe XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2291 8 thunderbird.exe XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1583 bp-dc47f80f-aa41-4b8c-98ce-5d2b42091016

can you reproduce this crash using trunk build (v3.2 alpha)? ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central-trunk/ backup your profile before testing. and note, your global index will reindex The reason for asking about trunk, is hunspell got updated on trunk a couple days ago. [1] #25 crash for 3.0.4, and exists in 3.1 ~3% of crashes have email addresses (pretty amazing). PMed them to see if anyone can reproduce with trunk build. [1] as noted in mdat newsgroup... On Sat, 12 Jun 2010 12:58:15 -0400, Wayne Mery wrote: > new 1.2.11 2010-05-06 > previous 1.2.8 2009-03-03 See: https://bugzilla.mozilla.org/show_bug.cgi?id=564608 Bug 564608 - Update Hunspell to 1.2.11 And: http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/2fa9ff59395cbcec

I've been unable to reproduce this at all, unfortunately. The breakpad ID I linked in comment #1 was from one of our employees.

bug 302775 is the last to change nearby lines. the crash is because: 4242 nsTextServicesDocument::FirstTextNodeInNextBlock(nsIContentIterator *aIterator) 4254 nsCOMPtr<nsIContent> content = do_QueryInterface(aIterator->GetCurrentNode()); content is null 4256 if (IsTextNode(content)) this is false. 4257 { 4262 } 4263 else if (!crossedBlockBoundary && IsBlockNode(content)) we pass null to IsBlockNode() which crashes.

The analysis in comment 4 is true, and it's very easy to add the null check, but I'm trying to understand what the underlying reason for the crash is.

Well, I guess taking a fix here won't hurt.

Comment on attachment 468915 [details] [diff] [review] Patch (v1) Can you put an NS_ERROR in here and leave the bug open? I think we should at some point understand how null can get in here.

(In reply to comment #7) > Comment on attachment 468915 [details] [diff] [review] > Patch (v1) > > Can you put an NS_ERROR in here and leave the bug open? I think we should at > some point understand how null can get in here. Sure, makes sense.

Comment on attachment 468928 [details] [diff] [review] Patch (v1.1) Approved for 1.9.2.11 and 1.9.1.14, a=dveditz

thanks to all, for the quick attention to this topcrash. reopening per comment 7

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/f2cfe1e0111f http://hg.mozilla.org/releases/mozilla-1.9.1/rev/df70c8bcf9b1

Should this bug be marked FIXED?

(In reply to comment #13) > Should this bug be marked FIXED? No, see comment 7 please.

OK, I give up, and I'm closing this. The possible NS_ERRORs that we get can probably be filed as new bugs. This bug is showing up in all sorts of queries all the time, and it's really misleading to leave this open.