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

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

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.

assuming reproducibility, this blocks tb3.

using milestones, not b1 flags.

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

Setting low priority until we can get STR.

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.

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.

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

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

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.

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.

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.

Yep I can reproduce with STR from comment 8.

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

(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

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

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 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 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.

Checked in, changeset id: 246:1ef1c2e849b1 Filed bug 453277 on the possibility for improving how nsAbView works wrt nulling out the tree.

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

(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.

(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.

(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.