451257 - Composing a message after the contacts sidebar was closed sometimes crashes Thunderbird

Status: VERIFIED FIXED

(MailNews Core :: Address Book, defect, P4)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080819030054 Shredder/3.0b1pre ID:20080819030054

Shredder will crash if you open a saved draft message which has a recipient for whom the name was changed in between. Looks like a bad synchronization with the OS X address book. See following steps to reproduce the crash:

1. Create a new card and set an email and last name
2. Compose a new message to that person and save it as draft
3. Change the card entry by removing the last name and set a first name
4. Go back to Shredder and open the draft folder
=> You can see that only the header pane shows the updated name. The recipient column still has the last name.
5. Try to open the saved draft message

=> The compose window is shown for about 5 seconds while the beach ball is displayed. The crash happens immediately.

Crash id: bp-54a8358a-6e34-11dd-b8fa-001a4bd43e5c

The stack trace doesn't look very helpful. But pasting anyway:
0  	thunderbird-bin  	pixman_malloc_abc  	
1 	thunderbird-bin 	pixman_malloc_abc 	
2 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
3 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
4 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
5 	libxpcom_core.dylib 	NS_InvokeByIndex_P 	
6 	thunderbird-bin 	MOZ_Z_inflateEnd 	
7 	thunderbird-bin 	MOZ_Z_inflateEnd 	
8 	libmozjs.dylib 	js_Invoke 	
9 	libmozjs.dylib 	JS_CompareValues 	
10 	libmozjs.dylib 	js_Invoke 	
11 	thunderbird-bin 	MOZ_Z_inflateEnd 	
12 	thunderbird-bin 	MOZ_Z_adler32 	
13 	libxpcom_core.dylib 	NS_InvokeByIndex_P 	
14 	libxpcom_core.dylib 	NS_InvokeByIndex_P 	
15 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
16 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
17 	thunderbird-bin 	NS_HexToRGB 	
18 	thunderbird-bin 	NS_HexToRGB 	
19 	thunderbird-bin 	NS_HexToRGB 	
20 	thunderbird-bin 	NS_HexToRGB 	
21 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
22 	thunderbird-bin 	NS_HexToRGB 	
23 	libxpcom_core.dylib 	NS_InvokeByIndex_P 	
24 	thunderbird-bin 	MOZ_Z_inflateEnd 	
25 	thunderbird-bin 	MOZ_Z_inflateEnd 	
26 	libmozjs.dylib 	js_Invoke 	
27 	libmozjs.dylib 	JS_CompareValues 	
28 	libmozjs.dylib 	js_Invoke 	
29 	thunderbird-bin 	MOZ_Z_inflateEnd 	
30 	thunderbird-bin 	MOZ_Z_adler32 	
31 	libxpcom_core.dylib 	NS_InvokeByIndex_P 	
32 	libxpcom_core.dylib 	NS_InvokeByIndex_P 	
33 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
34 	thunderbird-bin 	nsMsgDBFolder::GetMsgTextFromStream 	
35 	thunderbird-bin 	nsMsgDBFolder::GetMsgTextFromStream 	
36 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
37 	thunderbird-bin 	nsMsgProtocol::OnStopRequest 	
38 	thunderbird-bin 	nsMsgDBFolder::GetMsgTextFromStream 	
39 	thunderbird-bin 	XRE_GetFileFromPath 	
40 	thunderbird-bin 	XRE_GetFileFromPath 	
41 	libxpcom_core.dylib 	non-virtual thunk to nsHashPropertyBag::SetPropertyAsAUTF8String 	
42 	libxpcom_core.dylib 	NS_SetGlobalThreadObserver 	
43 	libxpcom_core.dylib 	NS_ProcessPendingEvents_P 	
44 	thunderbird-bin 	MOZ_Z_deflateInit2_ 	
45 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
46 	CoreFoundation 	CoreFoundation@0x72614 	
47 	CoreFoundation 	CoreFoundation@0x72cf7 	
48 	HIToolbox 	HIToolbox@0x2fda3 	
49 	HIToolbox 	HIToolbox@0x2faf5 	
50 	HIToolbox 	HIToolbox@0x2fa30 	
51 	AppKit 	AppKit@0x40504 	
52 	AppKit 	AppKit@0x3fdb7 	
53 	AppKit 	AppKit@0x38df2 	
54 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
55 	thunderbird-bin 	nsScriptableRegion::nsScriptableRegion 	
56 	thunderbird-bin 	XRE_main 	
57 	thunderbird-bin 	start 	
58 	thunderbird-bin 	start 	
59 	thunderbird-bin 	start 	
60 		@0x1

Comment 1

[Mark Banner (:standard8)]

FWIW I've just tried this and it worked fine. This looks more like a backend graphics problem that a mailnews problem.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks like. But I was able to crash Thunderbird again while using the same steps from comment 0. This time I didn't get a stack. Looks like we have to wait until this information is available again.

Comment 3

[David Ascher (:davida)]

assuming reproducibility, this blocks tb3.

Comment 4

[David Ascher (:davida)]

using milestones, not b1 flags.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This has nothing to do with the OS X address book. Some minutes ago I've seen the same behavior while trying to verify the fix on bug 366482. I opened a saved message, used the context menu first to edit the message and afterwards the main menu entry. After the last action some parts of the message compose window were disabled and no text filed into all the fields and body. After about 5s Shredder crashed.

Once again a useless crash id: bp-f924c259-7211-11dd-96a7-001a4bd43ef6

Comment 6

[David Ascher (:davida)]

Setting low priority until we can get STR.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I tried to find some STR to get it to crash reproducible but wasn't successful at all. At least I have some more information which could bring us closer to the problem:

The crash happens when trying to compose a message when the user has closed the contacts sidebar in the last compose window and canceled the composition. This way I was able to reproduce it each time until I decided to close Shredder after the canceling of the first compose window. After a restart the sidebar isn't shown anymore and I can open compose windows without crashing. Even showing/hiding the Contacts Sidebar doesn't bring up the crash. So there has to something which basically introduces this crash which I haven't found yet.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mark, could you try if this is reproducible for you?

1. Start Shredder and click Write to open a compose window
2. Make visible the Contacts Sidebar
3. Cancel composition by clicking the red close icon
4. Restart Shredder
5. Click Write to open the compose window and make sure the sidebar is shown
6. Close the sidebar
7. Cancel composition again
8. Click again on Write

=> After step 8 Shredder crashes for me each time. It doesn't depend on which address book you have select. Even happens with the Personal Addressbook. But the OS X one is still enabled.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also happens on Windows. Probably something in my profile has messed-up. I'll have a closer investigation.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Crashed thread reported by Apples crash reporter:

Thread 1 Crashed:
0   libSystem.B.dylib             	0x92bc8dbe __semwait_signal_nocancel + 10
1   libSystem.B.dylib             	0x92bbac87 usleep$NOCANCEL$UNIX2003 + 61
2   libSystem.B.dylib             	0x92bdc48b abort + 85
3   libSystem.B.dylib             	0x92baf007 internal_catch_exception_raise + 118
4   libSystem.B.dylib             	0x92b9d7b0 _Xexception_raise + 250
5   libSystem.B.dylib             	0x92b9d683 exc_server + 117
6   org.mozilla.thunderbird       	0x004305e9 nsScriptableRegion::nsScriptableRegion(nsIRegion*) + 3592573
7   libSystem.B.dylib             	0x92b186f5 _pthread_start + 321
8   libSystem.B.dylib             	0x92b185b2 thread_start + 34

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Finally I know what that happens. I've a broken abook.mab which causes Shredder to crash with the above given steps. Is there any way to clean up this file so already deleted address cards can be removed? Editing this file doesn't seem to be an easy job and I wont attach an testcase with a lot of included email addresses.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The steps above are WFM with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.16) Gecko/20080707 Thunderbird/2.0.0.16 Mnenhy/0.7.5.0 ID:2008070710

So it's a regression. When I've time I'll try to find out the regression range later today.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Surprisingly this regressed not too long ago. The regression window is between the following builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1pre) Gecko/2008070203 Thunderbird/3.0a2pre ID:2008070203

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2pre) Gecko/2008070304 Thunderbird/3.0a2pre ID:2008070304

Checkins within this time: http://tinyurl.com/5abp38

Possible candidates are bug 438035 or bug 443035. On both Mark is the assignee. 

Looks like that I should start to build my own debug builds again to get a better stack trace.

Comment 14

[Mark Banner (:standard8)]

Yep I can reproduce with STR from comment 8.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Top 20 frames from the debugger output:

#0  0x138d4560 in nsTreeSelection::GetSingle (this=0x18b52390, aSingle=0xbfff7da8) at /Users/henrik/mozilla/comm-central/src/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp:305
#1  0x138d51f4 in nsTreeSelection::RangedSelect (this=0x18b52390, aStartIndex=0, aEndIndex=0, aAugment=1) at /Users/henrik/mozilla/comm-central/src/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp:433
#2  0x1c0b23d2 in nsAbView::ReselectCards (this=0x18b5c260, aCards=0x18b6d220, aIndexCard=0x18b6d250) at /Users/henrik/mozilla/comm-central/src/mailnews/addrbook/src/nsAbView.cpp:1054
#3  0x1c0b5a7b in nsAbView::SortBy (this=0x18b5c260, colID=0xbfff80bc, sortDir=0x18b4fcf8) at /Users/henrik/mozilla/comm-central/src/mailnews/addrbook/src/nsAbView.cpp:716
#4  0x1c0b3be2 in nsAbView::SetView (this=0x18b5c260, aAddressBook=0x18b5c84c, aAbViewListener=0x0, aSortColumn=@0xbfff8660, aSortDirection=@0xbfff8670, aResult=@0xbfff8310) at /Users/henrik/mozilla/comm-central/src/mailnews/addrbook/src/nsAbView.cpp:243
#5  0x0048b2cd in NS_InvokeByIndex_P (that=0x18b5c260, methodIndex=3, paramCount=5, params=0xbfff83a4) at /Users/henrik/mozilla/comm-central/src/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
#6  0x1154548b in XPCWrappedNative::CallMethod (ccx=@0xbfff85f0, mode=XPCWrappedNative::CALL_METHOD) at /Users/henrik/mozilla/comm-central/src/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393
#7  0x1154fd65 in XPC_WN_CallMethod (cx=0x19c303b0, obj=0x180f1300, argc=4, argv=0xc9d360, vp=0xbfff870c) at /Users/henrik/mozilla/comm-central/src/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473
#8  0x0026271b in js_Invoke (cx=0x19c303b0, argc=4, vp=0xc9d358, flags=2) at jsinterp.cpp:1308
#9  0x00246093 in js_Interpret (cx=0x19c303b0) at /Users/henrik/mozilla/comm-central/src/mozilla/js/src/jsinterp.cpp:4964
#10 0x002627ac in js_Invoke (cx=0x19c303b0, argc=1, vp=0xc9d2bc, flags=0) at jsinterp.cpp:1326
#11 0x1153f26c in nsXPCWrappedJSClass::CallMethod (this=0x1bf641b0, wrapper=0x18b2e2b0, methodIndex=3, info=0x927630, nativeParams=0xbfff9e44) at /Users/henrik/mozilla/comm-central/src/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523
#12 0x1153707d in nsXPCWrappedJS::CallMethod (this=0x18b2e2b0, methodIndex=3, info=0x927630, params=0xbfff9e44) at /Users/henrik/mozilla/comm-central/src/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:565
#13 0x0048b5b0 in PrepareAndDispatch (self=0x18b50ef0, methodIndex=3, args=0xbfff9f64) at /Users/henrik/mozilla/comm-central/src/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93
#14 0x0048b60f in nsXPTCStubBase::Stub3 (this=0x18b50ef0) at xptcstubsdef.inc:1
#15 0x1359f3f3 in nsEventListenerManager::HandleEventSubType (this=0x19c72e40, aListenerStruct=0x19cd5138, aListener=0x18b50ef0, aDOMEvent=0x18ac99e0, aCurrentTarget=0x19c3022c, aPhaseFlags=4) at /Users/henrik/mozilla/comm-central/src/mozilla/content/events/src/nsEventListenerManager.cpp:1079
#16 0x135a0f85 in nsEventListenerManager::HandleEvent (this=0x19c72e40, aPresContext=0x19c6fe10, aEvent=0x18ac9a10, aDOMEvent=0xbfffa240, aCurrentTarget=0x19c3022c, aFlags=4, aEventStatus=0xbfffa244) at /Users/henrik/mozilla/comm-central/src/mozilla/content/events/src/nsEventListenerManager.cpp:1184
#17 0x135d2cfa in nsEventTargetChainItem::HandleEvent (this=0xbb2e20, aVisitor=@0xbfffa238, aFlags=4) at /Users/henrik/mozilla/comm-central/src/mozilla/content/events/src/nsEventDispatcher.cpp:211
#18 0x135d2de6 in nsEventTargetChainItem::HandleEventTargetChain (this=0xbb2e40, aVisitor=@0xbfffa238, aFlags=6, aCallback=0x0) at /Users/henrik/mozilla/comm-central/src/mozilla/content/events/src/nsEventDispatcher.cpp:242
#19 0x135d36e1 in nsEventDispatcher::Dispatch (aTarget=0x19c72e10, aPresContext=0x19c6fe10, aEvent=0x18ac9a10, aDOMEvent=0x18ac99e0, aEventStatus=0xbfffa328, aCallback=0x0) at /Users/henrik/mozilla/comm-central/src/mozilla/content/events/src/nsEventDispatcher.cpp:479
#20 0x135d3a16 in nsEventDispatcher::DispatchDOMEvent (aTarget=0x19c72e10, aEvent=0x0, aDOMEvent=0x18ac99e0, aPresContext=0x19c6fe10, aEventStatus=0xbfffa328) at /Users/henrik/mozilla/comm-central/src/mozilla/content/events/src/nsEventDispatcher.cpp:542

Comment 16

[[e-mail]]

(In reply to comment #15)
> Top 20 frames from the debugger output:
> 
> #0  0x138d4560 in nsTreeSelection::GetSingle (this=0x18b52390, aSingle=0xbfff7da8) at
> /Users/henrik/mozilla/comm-central/src/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp:305
If your line numbers match up with mine then mTree is null at this point.

Looking through the various tree selection methods it seems that:
GetSingle doesn't null-check
SetCurrentIndex null-checks and null-checks again
SetCurrentColumn doesn't null-check

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Before the crash occurs I get following assertion:

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../../../dist/include/xpcom/nsCOMPtr.h, line 811

Comment 18

[Mark Banner (:standard8)]

Attachment: Temporary fix (at least)

So it turns out that what we should be doing is to null our own mTree and mTreeSelection in ClearView() - I knew I should have kept our code in there. This is called when we close the compose window or at other times.

The abResultsTree.js code re-sets the tree once it has initialised the view and all is then happy.

Whilst nsTree* needs fixing, I think we should still fix this here.

The other possibility for what we should do would be to set the tree on nsAbView creation (or rather tell the tree the view when nsAbView is created), so only set them up once and only detach on shutdown. This should work, but I think I'd like to cover it in a follow up bug when I have more time, so that I can check if there are any performance regressions (and work out the code to handle those).

Comment 19

[[e-mail]]

Comment on attachment 336267 [details] [diff] [review]
Temporary fix (at least)

The code looks reasonable given the intent of the method, but passing the review over to someone who is known to be able to reproduce the crash ;-)

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 336267 [details] [diff] [review]
Temporary fix (at least)

Yes, that fixes the crash and improves the code after it was commented out by bug 438035.

Comment 21

[Mark Banner (:standard8)]

Checked in, changeset id: 246:1ef1c2e849b1

Filed bug 453277 on the possibility for improving how nsAbView works wrt nulling out the tree.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20080902031659 Shredder/3.0b1pre

Comment 24

[Ronald Killmer]

(In reply to comment #11)
> Finally I know what that happens. I've a broken abook.mab which causes Shredder
> to crash with the above given steps. Is there any way to clean up this file so
> already deleted address cards can be removed? Editing this file doesn't seem to
> be an easy job and I wont attach an testcase with a lot of included email
> addresses.

Commenting for the record.  The Abook.mab I cloned into my Shredder profile also contained deleted card data that did not purge when the contact was removed.  I am not aware that Tb 2 has misbehaved as a result.  Ref Bug 449759.

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #24)
> Commenting for the record.  The Abook.mab I cloned into my Shredder profile
> also contained deleted card data that did not purge when the contact was
> removed.  I am not aware that Tb 2 has misbehaved as a result.

This is bug 65086 by the way.

Comment 26

[Ronald Killmer]

(In reply to comment #25)
> (In reply to comment #24)
> > Commenting for the record.  The Abook.mab I cloned into my Shredder profile
> > also contained deleted card data that did not purge when the contact was
> > removed.  I am not aware that Tb 2 has misbehaved as a result.
> 
> This is bug 65086 by the way.

Thank You for the bug reference to the Abook size issue.  My comment #24 was to add related information from Bug 449759 that was duped to this bug.