524266 - TB3.0b4: Expanding threaded messages causes crash [@ memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) | nsMsgDBView::RemoveRows(unsigned int, int)]

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[Adam Nielsen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Thunderbird bin 3.0b4 and Shredder src 3.0b4 - Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.1.22) Gecko/20090809 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0

If I expand some messages in a particular folder I can make Thunderbird crash every time.

Reproducible: Always

Steps to Reproduce:
Would probably need a copy of the messages in my folder.  There are only about 20 messages and I am happy to post them (they are from a public mailing list), but there doesn't seem to be any export feature in Thunderbird so I am unsure of how.  I can zip up the folder on the IMAP server if you can take it in maildir format.
Actual Results:  
Expanding the message first only changes the little triangle icon (no new messages appear), collapsing then causes unrelated messages to become hidden, expanding a second time doesn't show the messages again, collapsing a second time then causes a crash.

Expected Results:  
No crash :-)  Correct messages shown/hidden.

Can't get the crash reporter working (I'm on 64-bit), here is the message printed to the console as the crash happens, and a stack trace:

###!!! ASSERTION: Invalid length: 'start + count <= Length()', file ../../../mozilla/dist/include/xpcom/nsTArray.h, line 598

#0  0x00007f9ef9b9bff7 in ?? () from /lib/libc.so.6
#1  0x00007f9ef9b9a69a in memmove () from /lib/libc.so.6
#2  0x00007f9ef0e562ba in nsMsgDBView::RemoveRows (this=0x7f9edb666800, viewIndex=3670015944, numRows=-1515870811) at nsMsgDBView.cpp:5182
#3  0x00007f9ef0e52223 in nsMsgDBView::CollapseByIndex (this=0x7f9edb666800, index=<value optimized out>, pNumCollapsed=0x7fff5c5bf2bc) at nsMsgDBView.cpp:4757
#4  0x00007f9ef0e55ae2 in nsMsgDBView::ToggleExpansion (this=0x7f9edb666800, index=<value optimized out>, numChanged=<value optimized out>) at nsMsgDBView.cpp:4587
#5  0x00007f9ef0e55b12 in nsMsgDBView::ToggleOpenState (this=0x7f9edabfff78, index=-624951352) at nsMsgDBView.cpp:1934
#6  0x00007f9efdc3d07e in NS_InvokeByIndex_P (that=0x7f9edb666810, methodIndex=24, paramCount=<value optimized out>, params=0x7fff5c5bf490) at xptcinvoke_x86_64_linux.cpp:208
#7  0x00007f9ef04473b6 in XPCWrappedNative::CallMethod (ccx=@0x7fff5c5bf730, mode=<value optimized out>) at xpcwrappednative.cpp:2454
#8  0x00007f9ef04519b4 in XPC_WN_CallMethod (cx=0x7f9eea44e400, obj=<value optimized out>, argc=1, argv=0x7f9eea49c1d0, vp=0x7fff5c5bf920) at xpcwrappednativejsops.cpp:1590
#9  0x00007f9efe367550 in js_Invoke (cx=0x7f9eea44e400, argc=<value optimized out>, vp=0x7f9eea49c1c0, flags=<value optimized out>) at jsinterp.cpp:1386
#10 0x00007f9efe34e673 in js_Interpret (cx=0x7f9eea44e400) at jsinterp.cpp:5179
#11 0x00007f9efe367591 in js_Invoke (cx=0x7f9eea44e400, argc=<value optimized out>, vp=0x7f9eea49c040, flags=<value optimized out>) at jsinterp.cpp:1394
#12 0x00007f9efe367b37 in js_InternalInvoke (cx=0x7f9eea44e400, obj=0x7f9ee682dc00, fval=140320218298432, flags=0, argc=1, argv=<value optimized out>, rval=0x7fff5c5bffb0) at jsinterp.cpp:1447
#13 0x00007f9efe310c2a in JS_CallFunctionValue (cx=0x7f9eea44e400, obj=0x7f9ee682dc00, fval=140320218298432, argc=1, argv=<value optimized out>, rval=<value optimized out>) at jsapi.cpp:5187
#14 0x00007f9eeb345cdc in nsJSContext::CallEventHandler (this=0x7f9eea4674a0, aTarget=<value optimized out>, aScope=0x7f9eea480c80, aHandler=0x7f9ed8c43840, aargv=0x7f9ed8c23cd0, arv=0x7fff5c5c01d0) at nsJSEnvironment.cpp:2085
#15 0x00007f9eeb393bd5 in nsJSEventListener::HandleEvent (this=0x7f9ed8c44290, aEvent=0x7f9ed8c70720) at nsJSEventListener.cpp:247
#16 0x00007f9eeb30f34e in nsXBLPrototypeHandler::ExecuteHandler (this=<value optimized out>, aTarget=<value optimized out>, aEvent=0x7f9ed8c70720) at nsXBLPrototypeHandler.cpp:341
#17 0x00007f9eeb30afb3 in nsXBLEventHandler::HandleEvent (this=0x7f9ee506cf80, aEvent=0x7f9ed8c70720) at nsXBLEventHandler.cpp:88
#18 0x00007f9eeb20e4ad in nsEventListenerManager::HandleEventSubType (this=<value optimized out>, aListenerStruct=0x7f9ee509e0a8, aListener=0x7f9ee506cf80, aDOMEvent=0x7f9ed8c70720, aCurrentTarget=0x4, aPhaseFlags=4294967236) at nsEventListenerManager.cpp:1098
#19 0x00007f9eeb20e7e4 in nsEventListenerManager::HandleEvent (this=0x7f9ee685ef80, aPresContext=<value optimized out>, aEvent=0x7fff5c5c0b40, aDOMEvent=0x7fff5c5c0910, aCurrentTarget=<value optimized out>, aFlags=<value optimized out>, aEventStatus=0x7fff5c5c0918) at nsEventListenerManager.cpp:1206
#20 0x00007f9eeb23056a in nsEventTargetChainItem::HandleEvent (this=<value optimized out>, aVisitor=@0x7fff5c5c0900, aFlags=6, aMayHaveNewListenerManagers=1549535200) at nsEventDispatcher.cpp:236
#21 0x00007f9eeb230763 in nsEventTargetChainItem::HandleEventTargetChain (this=<value optimized out>, aVisitor=@0x7fff5c5c0900, aFlags=6, aCallback=0x7fff5c5c09b0, aMayHaveNewListenerManagers=1) at nsEventDispatcher.cpp:300
#22 0x00007f9eeb230ccf in nsEventDispatcher::Dispatch (aTarget=<value optimized out>, aPresContext=<value optimized out>, aEvent=0x7fff5c5c0b40, aDOMEvent=0x0, aEventStatus=0x7fff5c5c108c, aCallback=<value optimized out>) at nsEventDispatcher.cpp:514
#23 0x00007f9eeafebff9 in PresShell::HandleEventInternal (this=0x7f9ee7b36000, aEvent=0x7fff5c5c0b40, aView=0x0, aStatus=0x7fff5c5c108c) at nsPresShell.cpp:6323
#24 0x00007f9eeafec69d in PresShell::HandleEventWithTarget (this=0x7f9ee7b36000, aEvent=0x7fff5c5c0b40, aFrame=<value optimized out>, aContent=<value optimized out>, aStatus=0x4) at nsPresShell.cpp:6228
#25 0x00007f9eeb215923 in nsEventStateManager::CheckForAndDispatchClick (this=<value optimized out>, aPresContext=<value optimized out>, aEvent=0x7fff5c5c12a0, aStatus=<value optimized out>) at nsEventStateManager.cpp:4073
#26 0x00007f9eeb21b97e in nsEventStateManager::PostHandleEvent (this=0x7f9ef12a7060, aPresContext=<value optimized out>, aEvent=0x7fff5c5c12a0, aTargetFrame=0x7f9ee5162830, aStatus=0x7fff5c5c108c, aView=0x7f9ee7bd5080) at nsEventStateManager.cpp:3036
#27 0x00007f9eeafec101 in PresShell::HandleEventInternal (this=0x7f9ee7b36000, aEvent=0x7fff5c5c12a0, aView=<value optimized out>, aStatus=0x7fff5c5c108c) at nsPresShell.cpp:6344
#28 0x00007f9eeafec803 in PresShell::HandlePositionedEvent (this=0x7f9ee7b36000, aView=<value optimized out>, aTargetFrame=0x7fff5c5c0f50, aEvent=0x7fff5c5c12a0, aEventStatus=0x7fff5c5c108c) at nsPresShell.cpp:6211
#29 0x00007f9eeafecd92 in PresShell::HandleEvent (this=0x7f9ee7b36000, aView=0x7f9ee7bd5080, aEvent=0x7fff5c5c12a0, aEventStatus=0x7fff5c5c108c) at nsPresShell.cpp:6071
#30 0x00007f9eeb337535 in nsViewManager::HandleEvent (this=<value optimized out>, aView=0x7f9ee7bd5080, aPoint=<value optimized out>, aEvent=0x7fff5c5c12a0, aCaptured=<value optimized out>) at nsViewManager.cpp:1400
#31 0x00007f9eeb33ad16 in nsViewManager::DispatchEvent (this=0x7f9ee7b088b0, aEvent=0x7fff5c5c12a0, aStatus=0x7fff5c5c11ec) at nsViewManager.cpp:1359
#32 0x00007f9eeb333bf9 in HandleEvent (aEvent=0x7fff5c5c12a0) at nsView.cpp:168
#33 0x00007f9eee3564a2 in nsWindow::DispatchEvent (this=0x7f9ee5c05f00, aEvent=0x7fff5c5c12a0, aStatus=@0x7fff5c5c131c) at nsWindow.cpp:577
#34 0x00007f9eee34d2b4 in nsWindow::OnButtonReleaseEvent (this=0x7f9ee5c05f00, aWidget=<value optimized out>, aEvent=0x7f9ee14c3c50) at nsWindow.cpp:2981
#35 0x00007f9eee3515c6 in button_release_event_cb (widget=0x7f9eea477580, event=0x7f9ee14c3c50) at nsWindow.cpp:5555
...

This was taken from Shredder 3.0b4 as I couldn't find a precompiled version with debugging enabled.

Comment 1

[Ludovic Hirlimann [:Usul]]

Xref : bug 517662 and bug 505960. We've fixed a few crashers recently. Could you try to reproduce with the latest nightly build from linux ? If it crashes please make sure to send the crash report and give us the crash id.

Comment 2

[Wayne Mery (:wsmwk)]

Adam  perhaps you missed seeing those before you file the bug? :)

re: 64bit, are you on AMD processor? (bug 427210)

Comment 3

[Adam Nielsen]

Sorry guys, grabbed the latest build from here and it still crashes:

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central-trunk/

Please let me know if I should be using a different download.

Although the crash reporter now runs (it used to complain about a missing library) all I can get it to do is say "don't run this program directly."  When Thunderbird segfaults it just dies, no crash reporter or anything appears.

I'm on an Intel Core2 processor.

Comment 4

[Mark Banner (:standard8)]

Please use the builds from:

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/

Comment 5

[Adam Nielsen]

Yep, still crashes, but with this version crashreporter doesn't run:

$ ./thunderbird
/home/adam/incoming/tb/nightly/thunderbird-3.0pre/crashreporter: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory

Comment 6

[David :Bienvenu]

you can copy the messages to a new local folder, and then just attach the mailbox file of that local folder. How is the folder sorted/grouped/threaded?

Comment 7

[Adam Nielsen]

Hmm okay, it looks like the problem originally surfaced when I moved the messages into that folder.  If I copy them into another folder the new folder works fine.  If I set up a fresh IMAP account and pull from the same folder, the messages also come in fine.

The only way I have been able to reproduce the problem on a different account is by pulling in a new IMAP folder, then replacing the .msf cache with the one from the broken folder.  That causes the tree view items to be added in the funny way that makes TB3 crash (although interestingly enough TB2 doesn't crash, the messages just disappear until you reopen the folder.)

Is it worth posting the .msf file?  It looks like fixing this crash will address the symptom rather than the original problem, unless looking at the raw data is able to tell you why it happened in the first place.

Comment 8

[David :Bienvenu]

yes, you can post or e-mail me the .msf file.

Comment 9

[Adam Nielsen]

I don't mind posting it, it's available at http://www.shikadi.net/files/synergy.msf (36kB)

If you set your folder to sort by date and enable threaded view, then replace the .msf file, when you go back to the folder there will be a message in the middle dated 2009-09-02 with the subject "Re: Combining a modifier..."  For me it's the only message in the folder that hasn't been expanded already.

When you expand and collapse it a few times it will cause the crash.

Comment 10

[Wayne Mery (:wsmwk)]

bienvenu, sounds familiar?

Comment 11

[David :Bienvenu]

thx for the reminder, wsmwk, I've been meaning to look at this.

Comment 12

[David :Bienvenu]

OK, the threading is messed up on that thread. I have a fix that makes us not crash when you expand/collapse the thread. I'm trying to fix it so we at least display the messages in the thread, even if we don't get the sub-threading right.

Comment 13

[David :Bienvenu]

Attachment: deal with failure to list threads in thread order

This patch does two things: 

If ListIdsInThreadOrder doesn't list any messages, we fall back to just listing the contents of the thread, which is better than nothing. And if ExpandByIndex fails to actually do anything, we don't set the thread as expanded, so we won't then crash when the user collapses the thread.

The way to test this is to create an imap folder called synergy, go offline, save the .msf file mentioned in this bug over the synergy.msf file in your profile, open the synergy folder, and expand/collapse the problematic thread the reporter describes.

The reason ListIdsInThreadOrder is failing is that the first header in the thread doesn't have any children in the thread, i.e., messages with it as its parent. I don't know how that happened. I'd like to repair that, but for now, this is a simpler, safer fix.

Comment 14

[David :Bienvenu]

fixed on trunk and 3.0 branch

Comment 15

[Wayne Mery (:wsmwk)]

david, did you file a bug for the last point of comment 13?

based on crash stats for 3.0b4, the sig for this crash should be memmove | nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int) | nsMsgDBView::RemoveRows(unsigned int, int)

bug 505960 appears to be the Mac equivalent of this crasher