129183 - Crash opening the address book after editing the history.mab file -TBTrunk [@ nsAddrDatabase::UpdateLowercaseEmailListName ]

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect)

Description

[Ninoschka Baca]

Trunk build 2002-03-05: Linux RH 7.1

Overview: While checking bug# 102319 I edited the history.mab file by removing
many  of the tops rows but I didn't remove very top rows. Now when I try to open
the address book it crashes. 

I tried another profile and edited the history.mab file by removing all of the
top  rows and it opens the address book without a crash so the problem might be
in the way I edited the file.

Steps to reproduce:
1. Select messages in the 3pane so entries are added to the CAB
2. Exit
3. Edit the history.mab file (so that some of the top entries are still present.
Just look at the history.mab file that I'm going to attach for an example)
4. Start the app
5. Select Tasks|Address Book

Actual Results: Crash
Expected Results: No crash

Comment 1

[Ninoschka Baca]

Attachment: history.mab file that caused the address book to crash

Comment 2

[Ninoschka Baca]

Adding bienvenu to the Cc: list since he was assigned bug# 102319.

Marking nsbeta1 because a crash shouldn't occur. Although I'm not sure why
anyone would want to edit their history.mab file.

Comment 3

[Ninoschka Baca]

Incident ID 3681455

nsAddrDatabase::UpdateLowercaseEmailListName()
nsAddrDatabase::InitExistingDB()
nsAddrDatabase::OpenMDB()
nsAddrDatabase::Open()
nsAbMDBDirFactory::CreateDirectory()
nsAbBSDirectory::CreateDirectoriesFromFactory()
nsAbBSDirectory::GetChildNodes()
nsAbDirectoryDataSource::GetTargets()
CompositeAssertionEnumeratorImpl::GetEnumerator()
CompositeEnumeratorImpl::HasMoreElements()
FilterInstantiations()
TestNode::Propagate()
TestNode::Propagate()
RootNode::Propagate()
nsXULContentBuilder::CreateContainerContents()
nsXULContentBuilder::CreateTemplateAndContainerContents()
nsXULContentBuilder::CreateContents()
EnsureContentsGenerated()
ChildCount()
nsXULElement::GetChildNodes()
nsBindingManager::GetContentListFor()
nsXBLBinding::GenerateAnonymousContent()
nsXBLService::LoadBindings()
nsCSSFrameConstructor::ConstructFrameInternal()
nsCSSFrameConstructor::ConstructFrame()
nsCSSFrameConstructor::ProcessChildren()
nsCSSFrameConstructor::ConstructXULFrame()
nsCSSFrameConstructor::ConstructFrameInternal()
nsCSSFrameConstructor::ConstructFrame()
nsCSSFrameConstructor::ProcessChildren()
nsCSSFrameConstructor::ConstructXULFrame()
nsCSSFrameConstructor::ConstructFrameInternal()
nsCSSFrameConstructor::ConstructFrame()
nsCSSFrameConstructor::ProcessChildren()
nsCSSFrameConstructor::ConstructDocElementFrame()
nsCSSFrameConstructor::ContentInserted()
StyleSetImpl::ContentInserted()
PresShell::InitialReflow()
nsXULDocument::StartLayout()
nsXULDocument::ResumeWalk()
nsXULDocument::EndLoad()
XULContentSinkImpl::DidBuildModel()
nsExpatDriver::DidBuildModel()
nsParser::DidBuildModel()
nsParser::ResumeParse()
nsParser::OnStopRequest()
nsJARChannel::OnStopRequest()
nsOnStopRequestEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0x1001e (0x4039501e)
libglib-1.2.so.0 + 0x117f3 (0x403967f3)
libglib-1.2.so.0 + 0x11dd9 (0x40396dd9)
libglib-1.2.so.0 + 0x11f8c (0x40396f8c)
libgtk-1.2.so.0 + 0x94803 (0x402ab803)
nsAppShell::Run()
nsAppShellService::Run()
netscape-bin + 0x7e89 (0x0804fe89)
netscape-bin + 0x86d7 (0x080506d7)
libc.so.6 + 0x1c177 (0x404e1177) 

Comment 4

[scottputterman]

marking nsbeta1-, because I don't expect people to be editing their history.mab
files.  If you can reproduce this crash through using the app, then please
renominate it.

Comment 5

[odi]

I am experiencing this bug when using the address book app.
I just removed some duplicate entries from the "Collected Addresses" address
book, which is in fact history.mab, by repeatedly pressing the DEL key.
While deleting an entry the address book app hang and blocked whole mozilla. I
had to terminate the address book process and restart mozilla.
As soon as I opened the address book app again the same hang occured.
After manually removing the history.mab file the address book worked again.

Build: 2002031104 (Moz 0.9.9) on Win98
I will attach the damaged history.mab

Comment 6

[odi]

Attachment: damaged file of comment #5

Comment 7

[Sean Gao]

I test the history.mab of comment #5 in mozilla 1.1 release. 
It is OK even when the last entry is eliminated(with DEL key). 
Do you guys still meet this problem? 

Comment 8

[odi]

WFM, I don't see this crash any more on 1.2alpha
Deleting entries from an address book seems much smoother now, no more crashes
when DEL key is pressed quickly repeatedly.

Comment 9

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 10

[Jay Patel [:jay]]

A crash similar to the one reported here has been showing up in recent
ThunderbirdTrunk Talkback data. The stack looks the same, so this might be worth
looking into.

Here is a recent incident:
Incident ID: 3418505
Stack Signature	nsAddrDatabase::UpdateLowercaseEmailListName 8d1fb698
Product ID	ThunderbirdTrunk
Build ID	2005013106
Trigger Time	2005-01-31 21:12:13.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	THUNDE~1.EXE + (0045820f)
URL visited	
User Comments	replying to an email/
Since Last Crash	35 sec
Total Uptime	35 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp,
line 1145
Stack Trace 	
nsAddrDatabase::UpdateLowercaseEmailListName 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp,
line 1145]
nsAddrDatabase::InitExistingDB 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp,
line 1094]
nsAddrDatabase::OpenInternal 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp,
line 663]
nsAddrDatabase::Open 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp,
line 574]
nsAbMDBDirFactory::CreateDirectory 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAbMDBDirFactory.cpp,
line 159]
nsAbBSDirectory::CreateDirectoriesFromFactory 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAbBSDirectory.cpp,
line 120]
nsAbBSDirectory::GetChildNodes 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/addrbook/src/nsAbBSDirectory.cpp,
line 216]
nsMsgCompose::GetABDirectories 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/compose/src/nsMsgCompose.cpp,
line 3697]
nsMsgCompose::CheckAndPopulateRecipients 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mailnews/compose/src/nsMsgCompose.cpp,
line 3912]
XPTC_InvokeByIndex 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1293]
js_Interpret 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3565]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1313]
nsXPCWrappedJSClass::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
XPTC_InvokeByIndex 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1293]
js_Interpret 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3565]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1313]
js_InternalInvoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1390]
JS_CallFunctionValue 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c,
line 3804]
nsJSContext::CallEventHandler 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1354]
nsJSEventListener::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1519]
nsEventListenerManager::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1596]
nsXULElement::HandleDOMEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2045]
nsXULElement::HandleDOMEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 1874]
PresShell::HandleDOMEventWithTarget 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5998]
nsButtonBoxFrame::MouseClicked 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp,
line 177]
nsButtonBoxFrame::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp,
line 146]
PresShell::HandleEventInternal 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5963]
PresShell::HandleEventWithTarget 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5837]
nsEventStateManager::CheckForAndDispatchClick 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2954]
nsEventStateManager::PostHandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 1935]
PresShell::HandleEventInternal 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5971]
PresShell::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5775]
nsViewManager::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2424]
nsViewManager::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2151]
HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1103]
nsWindow::DispatchMouseEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5402]
ChildWindow::DispatchMouseEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5653]
nsWindow::WindowProc 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1389]
USER32.dll + 0x2a420 (0x77e3a420)
USER32.dll + 0x4605 (0x77e14605)
USER32.dll + 0xa7ba (0x77e1a7ba)
nsAppStartup::Run 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
main 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Clobber/mozilla/mail/app/nsMailApp.cpp,
line 61]
KERNEL32.DLL + 0x2893d (0x7c59893d)

This was originally logged as a Mozilla bug, but changing the product to
Thunderbird to see if we can get people looking at this.

Comment 11

[Bastiaan Jacques]

Attachment: Add NULL check

Fixes the crash described in comment 1.

Comment 12

[David :Bienvenu]

Comment on attachment 175725 [details] [diff] [review]
Add NULL check

I think a better fix is to check in nsresult nsAddrDatabase::InitExistingDB()
for an error getting that table.

Comment 13

[Bastiaan Jacques]

Attachment: Add check to InitExistingDB()

Okay. But I think the NULL check from the previous patch should go in as well.
Note that GetLastRecordKey() already has an identical NULL check.

Comment 14

[David :Bienvenu]

Comment on attachment 175742 [details] [diff] [review]
Add check to InitExistingDB()

I don't know if that extra null check is needed. The idea is that we should not
get to any of the other methods in the db if we can't create the main table,
because we shouldn't be able to open it.

Comment 15

[Bastiaan Jacques]

In essence I agree with you.. but can we be sure that the programmer will check
each return value? If we could, would we be here talking about NULL checks?

In any case, if you decide to leave the NULL check out, you should also consider
removing the NULL check in GetLastRecordKey().

Comment 16

[timeless]

mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp 	1.123

Comment 17

[Bastiaan Jacques]

Attachment: Really fix the crash. I mean it.

Unfortunately, the second patch does not actually prevent the crash. Indeed, it
seems that even if GetTable() appears to succeed, m_mdbPabTable can still be
zero or NULL. This patch adds a check for m_mdbPabTable.

Comment 18

[David :Bienvenu]

Comment on attachment 176199 [details] [diff] [review]
Really fix the crash. I mean it.

can you send me such a db that causes this problem, so I can see why Mork is
not returning an error but is returning a null table?

Comment 19

[Bastiaan Jacques]

Attachment: history.mab crasher

This is an example of a history.mab that crashes tbird (and presumably also the
suite).

Comment 20

[Bastiaan Jacques]

Attachment 176199 [details] [diff] checked in by [e-mail] on 2005-03-08 at 07:58.