834487 - crash during spell check replacement in nsTextServicesDocument::FirstTextNodeInCurrentBlock. Users loses composed mail

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect, P3)

Description

[Wayne Mery (:wsmwk)]

this crash starts in TB16
top 50 crash for TB17

almost all crashes cite spell check, like this bp-2f9fbbe0-994d-4a96-88f9-36d432121229  ... "so tired of crash during spell check"

0	xul.dll	nsTextServicesDocument::FirstTextNodeInCurrentBlock	editor/txtsvc/src/nsTextServicesDocument.cpp:3172
1	xul.dll	nsTextServicesDocument::CreateOffsetTable	editor/txtsvc/src/nsTextServicesDocument.cpp:3379
2	xul.dll	nsTextServicesDocument::LastSelectedBlock	editor/txtsvc/src/nsTextServicesDocument.cpp:624
3	xul.dll	mozSpellChecker::SetupDoc	extensions/spellcheck/src/mozSpellChecker.cpp:412
4	xul.dll	mozSpellChecker::NextMisspelledWord	extensions/spellcheck/src/mozSpellChecker.cpp:71
5	xul.dll	nsEditorSpellCheck::GetNextMisspelledWord	editor/composer/src/nsEditorSpellCheck.cpp:344
6	xul.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70

Comment 1

[Wayne Mery (:wsmwk)]

topcrash for TB17

Comment 2

[Wayne Mery (:wsmwk)]

ehsan, will a testcase be needed for this?

Comment 3

[(no longer active)]

(In reply to comment #2)
> ehsan, will a testcase be needed for this?
It would be great, yes.

Comment 4

[Wayne Mery (:wsmwk)]

Laurent, do you have somebody who can test the following ...?

Ehsan, according to reporter of bp-a7ad5628-1768-4e53-b42b-15e782130228 ...
"it is only when using the French (xx-classique+reforme1990) dictionary and only when one or more words contain letters with accents."
I haven't tried it myself.

That's the best I've got from attempting to contact a dozen crash reporters.

Comment 5

[(no longer active)]

I'm afraid that there is not much that we can do here without a testcase.

Comment 6

[Laurent Bauvens]

(In reply to Wayne Mery (:wsmwk) from comment #4)
> Laurent, do you have somebody who can test the following ...?
> 
> Ehsan, according to reporter of bp-a7ad5628-1768-4e53-b42b-15e782130228 ...
> "it is only when using the French (xx-classique+reforme1990) dictionary and
> only when one or more words contain letters with accents."

I tested few times and experienced a crash once. It seems to happen randomly but triggered by a click on the Replace button.

- Install the new extended French dictionary (addon listed as "Dictionnaire français 4.9")
- Edit a new message
- Type "Je hais les gend énèrevéées car ils m'énèrevent vrément"
- Start spell checking via the Options menu
 * The spell checking dialog box appears
- Select (fr-classic|fr-classic-reform|fr-modern|fr-reform) in Language list
 * "gend" is found
- select a word in the suggested list of words
- click on the Replace button
 * (Here Thunderbird sometimes freezes)

I never experienced a crash with the French dictionary bundled with Thunderbird.

Comment 7

[Scoobidiver (away)]

It's #46 crasher in TB 17.0.7 so not a top crasher.

Comment 8

[Wayne Mery (:wsmwk)]

coding this topcrash for Thunderbird because 
- combined crash count with bug 835314 puts this is near topcrash for TB24.0.1 (and apparently has been also for version 17), and 
- many users lose data when message is neither saved nor sent because of crash.  Indeed several users wrote me they compose their email outside of thunderbird and then paste into compose window, because of the badness of this issue. (not suggesting however that user who crashes sees dataloss)

Still no testcase.  But doesn't the crash have the data needed to attempt a fix?  


bp-c3ab324b-3c5b-4742-abf6-4e4d72130728
0	xul.dll	nsTextServicesDocument::FirstTextNodeInCurrentBlock(nsIContentIterator *)	editor/txtsvc/src/nsTextServicesDocument.cpp
1	xul.dll	nsTextServicesDocument::CreateOffsetTable(nsTArray<OffsetEntry *,nsTArrayDefaultAllocator> *,nsIContentIterator *,nsTextServicesDocument::TSDIteratorStatus *,nsIDOMRange *,nsString *)	editor/txtsvc/src/nsTextServicesDocument.cpp
2	xul.dll	nsTextServicesDocument::LastSelectedBlock(nsITextServicesDocument::TSDBlockSelectionStatus *,int *,int *)	editor/txtsvc/src/nsTextServicesDocument.cpp
3	xul.dll	mozSpellChecker::SetupDoc(int *)	extensions/spellcheck/src/mozSpellChecker.cpp
4	xul.dll	mozSpellChecker::NextMisspelledWord(nsAString_internal &,nsTArray<nsString,nsTArrayDefaultAllocator> *)	extensions/spellcheck/src/mozSpellChecker.cpp 

http://hg.mozilla.org/releases/mozilla-esr17/annotate/483c883197a8/extensions/spellcheck/src/mozSpellChecker.cpp#l71
hg@1      53 NS_IMETHODIMP
mwu@79146 54 mozSpellChecker::SetDocument(nsITextServicesDocument *aDoc, bool aFromStartofDoc) 

http://hg.mozilla.org/releases/mozilla-esr17/annotate/483c883197a8/extensions/spellcheck/src/mozSpellChecker.cpp#l412
hg@1 405 nsITextServicesDocument::TSDBlockSelectionStatus blockStatus;
ehsan@108463 406 int32_t selOffset;
ehsan@108463 407 int32_t selLength;
hg@1 408 *outBlockOffset = 0;
hg@1 409
hg@1 410 if (!mFromStart)
hg@1 411 {
hg@1 412 rv = mTsDoc->LastSelectedBlock(&blockStatus, &selOffset, &selLength); 

http://hg.mozilla.org/releases/mozilla-esr17/annotate/483c883197a8/editor/txtsvc/src/nsTextServicesDocument.cpp#l624
hg@1 621 mIteratorStatus = nsTextServicesDocument::eValid;
hg@1 622
hg@1 623 result = CreateOffsetTable(&mOffsetTable, mIterator, &mIteratorStatus,
ayg@106310 624 mExtent, nullptr); 

http://hg.mozilla.org/releases/mozilla-esr17/annotate/483c883197a8/editor/txtsvc/src/nsTextServicesDocument.cpp#l3172
hg@1 3157 nsTextServicesDocument::FirstTextNodeInCurrentBlock(nsIContentIterator *iter)
hg@1 3158 {
ehsan@43807 3159 NS_ENSURE_TRUE(iter, NS_ERROR_NULL_POINTER);
hg@1 3161 ClearDidSkip(iter);
hg@1 3163 nsCOMPtr<nsIContent> last;
hg@1 3165 // Walk backwards over adjacent text nodes until
hg@1 3166 // we hit a block boundary:
hg@1 3168 while (!iter->IsDone())
hg@1 3169 {
ayg@101201 3170 nsCOMPtr<nsIContent> content = iter->GetCurrentNode()->IsContent()
ayg@101201 3171 ? iter->GetCurrentNode()->AsContent()
ayg@106310 3172 : nullptr; 

http://hg.mozilla.org/releases/mozilla-esr17/annotate/483c883197a8/editor/txtsvc/src/nsTextServicesDocument.cpp#l3379
...
hg@1 3366 if (aIterRange)
hg@1 3367 {
hg@1 3368 result = GetRangeEndPoints(aIterRange,
hg@1 3369 getter_AddRefs(rngStartNode), &rngStartOffset,
hg@1 3370 getter_AddRefs(rngEndNode), &rngEndOffset);
hg@1 3372 NS_ENSURE_SUCCESS(result, result);
hg@1 3373 }
hg@1 3374
hg@1 3375 // The text service could have added text nodes to the beginning
hg@1 3376 // of the current block and called this method again. Make sure
hg@1 3377 // we really are at the beginning of the current block:
hg@1 3378
hg@1 3379 result = FirstTextNodeInCurrentBlock(aIterator);

Comment 9

[ISHIKAWA, Chiaki]

(In reply to Laurent Bauvens from comment #6)
> (In reply to Wayne Mery (:wsmwk) from comment #4)
> > Laurent, do you have somebody who can test the following ...?
> > 
> > Ehsan, according to reporter of bp-a7ad5628-1768-4e53-b42b-15e782130228 ...
> > "it is only when using the French (xx-classique+reforme1990) dictionary and
> > only when one or more words contain letters with accents."
> 
> I tested few times and experienced a crash once. It seems to happen randomly
> but triggered by a click on the Replace button.
> 
> - Install the new extended French dictionary (addon listed as "Dictionnaire
> français 4.9")
> - Edit a new message
> - Type "Je hais les gend énèrevéées car ils m'énèrevent vrément"
> - Start spell checking via the Options menu
>  * The spell checking dialog box appears
> - Select (fr-classic|fr-classic-reform|fr-modern|fr-reform) in Language list
>  * "gend" is found
> - select a word in the suggested list of words
> - click on the Replace button
>  * (Here Thunderbird sometimes freezes)
> 
> I never experienced a crash with the French dictionary bundled with
> Thunderbird.


I tried to reproduce this.
Unfortunately, the dictionary has advanced to 4.12 version it seems.
Anyway, here are a few observations:
> - Type "Je hais les gend énèrevéées car ils m'énèrevent vrément"

Well, I simply copy and pasted. But I realize that there may be an issue
of character code issue.
I wonder what character code the bug reporters used.
It *may* have bearings on the buggy behavior.

> - click on the Replace button

I am used to spell-checking my English messages.
In contrast to it, the initial replacement seems to take a little longer, but
I doubt if it is for real. But if I DID feel there was a delay,
there may be something in the processing. Hmm...

Another thing may require clarification.
Do the reporters use HTML mail composition or not? (see below).

I am not familiar with the text composition code at all.

*HOWEVER*, note the following:
this is an excerpt from |make mozmill| run on my local PC.
(This is a DEBUG BUILD of TB and I have removed lines  like
 --DOCSHELL 0x5cd1270 == 28 [id = 57]
 --DOMWINDOW == 73 (0x3a8aa28) [serial = 73] [outer = (nil)] [url = about:blank]

I see many warnings from text composition tests all the time.

In the following note the warning about text nodes, etc.
There may something there.
Oh, this nextNode warnings is only for the HTML editing.
So whether HTML e-mail is composed or not may matter.

"NS_ENSURE_TRUE(aSelection->GetRangeCount()) failed" is seen always,
and I wonder if there is a bad assumption about a selection exists at
the startup of a document composition or something.

The following line and the line that follows this look disturbing. 
WARNING: NS_ENSURE_TRUE(editor) failed : file /REF-COMM-CENTRAL/comm-central/mozilla/extensions/spellcheck/src/mozInlineSpellChecker.cpp, line 1824


Here is the excerpt:

TEST-START | /REF-COMM-CENTRAL/comm-central/mail/test/mozmill/message-header/test-reply-to-list-from-address-selection.js | test_Reply_To_List_From_Address
Step Pass: {"function": "Controller.keypress()"}
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 8470
WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2347
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 8470
WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2347
WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2347
WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2347
WARNING: NS_ENSURE_TRUE(parentObject) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/accessible/src/atk/AccessibleWrap.cpp, line 1261
WARNING: NS_ENSURE_TRUE(parentObject) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/accessible/src/atk/AccessibleWrap.cpp, line 1261
WARNING: NS_ENSURE_TRUE(aSelection->GetRangeCount()) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/base/nsEditor.cpp, line 3805
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/base/nsEditor.cpp, line 3784
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp, line 316
WARNING: NS_ENSURE_TRUE(sheet) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 2959
WARNING: NS_ENSURE_TRUE(aSelection->GetRangeCount()) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/base/nsEditor.cpp, line 3805
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/base/nsEditor.cpp, line 3784
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/text/nsTextEditRules.cpp, line 417
WARNING: NS_ENSURE_TRUE(parentObject) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/accessible/src/atk/AccessibleWrap.cpp, line 1261
WARNING: NS_ENSURE_TRUE(nextNode) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 944
WARNING: NS_ENSURE_TRUE(nextNode) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 944
WARNING: NS_ENSURE_TRUE(nextNode) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 944
WARNING: NS_ENSURE_TRUE(nextNode) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 944
WARNING: NS_ENSURE_TRUE(nextNode) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 944
WARNING: NS_ENSURE_TRUE(nextNode) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 944
WARNING: NS_ENSURE_TRUE(aSelection->GetRangeCount()) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/base/nsEditor.cpp, line 3805
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/base/nsEditor.cpp, line 3784
WARNING: NS_ENSURE_SUCCESS(res, res) failed with result 0x80004005: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/text/nsTextEditRules.cpp, line 417
WARNING: NS_ENSURE_TRUE(ps) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 2963
WARNING: NS_ENSURE_TRUE(ps) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 2963
WARNING: NS_ENSURE_TRUE(ps) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 2963
WARNING: NS_ENSURE_TRUE(ps) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 2963
WARNING: NS_ENSURE_TRUE(editor) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/extensions/spellcheck/src/mozInlineSpellChecker.cpp, line 1824
WARNING: NS_ENSURE_TRUE(editor) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/extensions/spellcheck/src/mozInlineSpellChecker.cpp, line 708
++DOMWINDOW == 79 (0x500be98) [serial = 293] [outer = 0x5b96698]
WARNING: /tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3429: signal name `selection_changed' is invalid for instance `0x488c310' of type `MaiAtkType3': 'glib warning', file /REF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsSigHandlers.cpp, line 127
  [ ... rest omitted ... ]


TIA

Comment 11

[Wayne Mery (:wsmwk)]

The signature for bug 835314 and this bug rank the crash at #15. Let's see if you can give this some solid attention.

Comment 12

[Ryan VanderMeulen (PTO, back July 27)]

This is still showing up in the Thunderbird crash stats, but it seems highly unlikely we're going to be able to usefully find a regression range at this point even if a testcase were to emerge.

Comment 13

[Wayne Mery (:wsmwk)]

currently ranked #144, so not topcrash as it was still in version 31

Comment 14

[Wayne Mery (:wsmwk)]

https://support.mozilla.org/en-US/questions/110666 reports this, and Matt has some data in hand

Comment 15

[Jorg K (CEST = GMT+2)]

https://support.mozilla.org/en-US/questions/110666 = Page Not Found.

Comment 16

[Wayne Mery (:wsmwk)]

 https://support.mozilla.org/en-US/questions/1106669  (chopped a digit)

Comment 17

[Matt]

I have the MSF and drafts mbox from the relevant user,  both before and after the index build.  So there are two MSF files.  The MSF was obviously corrupt.  But perhaps there is something in the mbox that might help with this bug.

Comment 18

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 19

[Wayne Mery (:wsmwk)]

still an issue, including these signatures
nsTextServicesDocument::FirstTextNodeInNextBlock
nsTextServicesDocument::CreateOffsetTable

Comment 20

[Makoto Kato [:m_kato]]

This seems to be only on ESR52 tree.

Comment 21

[Wayne Mery (:wsmwk)]

No crashes so far for version 60*.  But this is low rate crash so we need to have a higher user population on v60.

* https://crash-stats.mozilla.com/search/?signature=~nsTextServicesDocument&product=Thunderbird&date=%3E%3D2018-07-20T21%3A48%3A11.000Z&date=%3C2018-08-20T21%3A48%3A11.000Z&_sort=-date&_facets=signature&_facets=version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-version

Comment 22

[Phoenix]

Resolved per whiteboard, no crashes for 60* using link in Comment 21 with adjusted date