Sending longish plaintext message hangs Thunderbird



MailNews Core
10 years ago
3 years ago


(Reporter: bz, Unassigned)


(Depends on: 2 bugs, {perf, regression, testcase})

perf, regression, testcase
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 -
wanted-thunderbird3 +

Firefox Tracking Flags

(Not tracked)



(2 attachments)

BUILD: Thunderbird


1) Start composing a message
2) Paste in 300KB of text
3) Send

ACTUAL RESULTS: Application is unresponsive for several minutes


I don't recall ever running into this with Thunderbird 1.5, but it's possible I never sent messages this long....

I profiled the hang in Shark, and it looks like all the time is spent calling IndexOf() on nsIContents.  The callstack to the IndexOf call is:

nsMsgMailNewsUrl::SetUrlState(int, unsigned)	
nsUrlListenerManager::BroadcastChange(nsIURI*, nsUrlNotifyType, unsigned)	
nsUrlListenerManager::BroadcastChange(nsIURI*, nsUrlNotifyType, unsigned)	
nsImapMailFolder::OnCopyCompleted(nsISupports*, unsigned)	
nsMsgCopyService::FindRequest(nsISupports*, nsIMsgFolder*)	
nsMsgCopyService::ClearRequest(nsCopyRequest*, unsigned)	
nsMsgGroupThread::~nsMsgGroupThread [in-charge deleting]()	
nsMsgComposeSendListener::RemoveCurrentDraftMessage(nsIMsgCompose*, int)	
GetNodeLocation(nsIDOMNode*, nsCOMPtr<nsIDOMNode>*, int*)	
nsHTMLEditor::~nsHTMLEditor [in-charge]()	
nsHTMLEditor::ParseCFHTML(nsCString&, unsigned short**, unsigned short**)	
nsHTMLEditRules::WillDeleteSelection(nsISelection*, short, int*, int*)	
nsTypedSelection::StartAutoScrollTimer(nsPresContext*, nsIView*, nsPoint&, unsigned)	
nsBlinkTimer::AddBlinkFrame(nsPresContext*, nsIFrame*)	
nsSelection::BidiLevelFromClick(nsIContent*, unsigned)	
nsTypedSelection::MoveIndexToNextMismatch(int*, nsIDOMNode*, int, nsTArray<int> const*, int)	
nsTypedSelection::FindInsertionPoint(nsTArray<int> const*, nsIDOMNode*, int, unsigned (*)(nsIDOMNode*, int, nsIDOMRange*, int*), int*)	
nsTypedSelection::MoveIndexToNextMismatch(int*, nsIDOMNode*, int, nsTArray<int> const*, int)	
nsRange::ComparePoints(nsIDOMNode*, int, nsIDOMNode*, int)	
nsRange::IsIncreasing(nsIDOMNode*, int, nsIDOMNode*, int)	
nsAttrAndChildArray::IndexOfChild(nsIContent*) const	

though this is the release build, so the symbols might be suspect, of course.
Flags: blocking-thunderbird3?

Comment 1

10 years ago
It would be interesting to know if this happens on trunk builds.
Keywords: qawanted
I'll try to set up a complete dummy profile to use with trunk builds, but it might be a while before I get to it.


10 years ago
Product: Core → MailNews Core


10 years ago
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-

Comment 3

10 years ago
I just tried this on thunderbird linux/trunk, pasted a 300k+ lorem ipsum into thunderbird (the plain text and also html composition) and sent it. Went out in < 10sec, no hang. 

Boris: still see this on trunk?
Not sure.  I can't reproduce on trunk, but neither can I reproduce on branch with the files I've tried.  I guess I should have saved that text file....

Comment 5

10 years ago
Setting wanted- for now; feel free to renominate if we can come up with steps to reproduce...
Flags: wanted-thunderbird3+ → wanted-thunderbird3-
Created attachment 372863 [details]
500kb sent test file

I think I can somehow reproduce this with an arbitrary 500+kb text email.

Stack coming up.
Created attachment 372864 [details]

So what happens is that I try sending a long plain text email from one gmail account to another - everything seems ok until the status message hits "sending login info" and then Thunderbird hangs for 5-10 minutes before unfreezing.

If I'm reading the sample correctly, it's spending lots of time at nsAttrAndChildArray::IndexOfChild
Renominating, please let me know if there's more information to provide.

Also, my 500kb test email was produced by pasting the content from mailWindowOverlay.js file into the Compose area 5 times (5x100 = 500kb).
Severity: normal → major
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3-
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Keywords: qawanted → testcase
Summary: Sending longish plaintext message hangs Thunderbird 2 → Sending longish plaintext message hangs Thunderbird
I'm on latest comm-central-1.9.1 debug build in Mac Leopard 10.5.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090415 Lightning/1.0pre Shredder/3.0b3pre
Ah, yeah.  That stack matches the one I saw, except it's a lot clearer on what the problem is.  It seems we're trying to select all 500KB of text, and the textframe selection code is being super-slow about it.

And in particular, the HasSelectionOverflowingDecorations call made from nsTextFrame::SetSelected is fairly slow in this case.

Marking dependent on bug 485446.

That said, the IndexOf() slowness is a real issue here.  Jonas, the problem is that we're comparing all sorts of stuff to range endpoints, so we keep making lots and lots of IndexOf() calls in pairs: first on the range endpoint, then on the node being compared.  The two are further and further apart, so the indexof cache just thrashes without being useful...

I wonder whether we can somehow make comparisons to range endpoints faster (e.g. cache the indexes of all ancestors of the start/end parent in the range or some such).  Worth filing a bug on?
GIven the rarity of the use case, I don't think this is blocking.  (especially given that it depends on a gecko bug, etc).
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-


9 years ago
Duplicate of this bug: 366458


9 years ago
OS: Mac OS X → All
You need to log in before you can comment on or make changes to this bug.