Build: Linux 1999110408 OS: RH6.0 After you edit a name card and close the address book, selecting Tasks | Address Book will crash the browser. Steps of reproduce: 1. Have one name card in your address book. 2. Open the edit window for the name card. 3. Click on OK button after you change something on the edit window. 4. Close the address book window. 5. Select Tasks | Address Book It will crash the browser.

ji - can you try this on Win32 as well?

It doesn't crash Win32 build with the same operation.

It doesn't crash on Windows but the list dislay is gone! when you re-open the folder which contains the new addition. Other folders are OK. This problem persists until mozilla is quit and re-started. This should be another bug. Is there a bug filed on this?

Marking as M12, please change to M11 if needed.

Putting on PDT+ radar.

Update: Using M11 builds 1999111017 on Win98 and linux and following the steps, I don't crash on linux or lose my display list. I will check the lastest M11 and the latest M12 too.

Checked again on M11 111017 and M12 111508 Linux build. The problem is gone. Will wait latest M11 to check it again.

Checked Linux M11 111218 build. This problem is not repro anymore.

Chris, this is the crasher we talked about earlier. Sending to you... Thanks.

looking...

Relevant stack seems to be in DB code (see below). I am pretty lost here. As best I can tell, things start to go wrong in morkTable::NewTableRowCursor: looks like mTable_Store->mPort_Heap is null, and this is propogating down through some fancy overload of operator new. Reassigning to bienvenu for further investigation. Adding davidmc to cc list. #0 0x40d084e8 in morkNode::morkNode (this=0x0, ev=0x86c91b8, inUsage=@0x40d2d4cc, ioHeap=0x0) at morkNode.cpp:278 #1 0x40d1fc16 in morkBead::morkBead (this=0x0, ev=0x86c91b8, inUsage=@0x40d2d4cc, ioHeap=0x0, inBeadColor=0) at morkBead.cpp:83 #2 0x40d099ca in morkObject::morkObject (this=0x0, ev=0x86c91b8, inUsage=@0x40d2d4cc, ioHeap=0x0, inBeadColor=0, ioHandle=0x0) at morkObject.cpp:81 #3 0x40d01f1a in morkCursor::morkCursor (this=0x0, ev=0x86c91b8, inUsage=@0x40d2d4cc, ioHeap=0x0) at morkCursor.cpp:71 #4 0x40d19d56 in morkTableRowCursor::morkTableRowCursor (this=0x0, ev=0x86c91b8, inUsage=@0x40d2d4cc, ioHeap=0x0, ioTable=0x8765770, inRowPos=-1) at morkTableRowCursor.cpp:89 #5 0x40d18d85 in morkTable::NewTableRowCursor (this=0x8765770, ev=0x86c91b8, inRowPos=-1) at morkTable.cpp:738 #6 0x40cfabed in orkinTable::GetTableRowCursor (this=0x87659e8, mev=0x86c9260, inRowPos=-1, acqCursor=0x86b64fc) at orkinTable.cpp:559 #7 0x415650e9 in nsAddrDBEnumerator::First (this=0x86b64e8) at nsAddrDatabase.cpp:2545 #8 0x4012dbd3 in nsAdapterEnumerator::HasMoreElements (this=0x87ce438, aResult=0xbfffa31c) at nsEnumeratorUtils.cpp:174 #9 0x4044893e in CompositeEnumeratorImpl::HasMoreElements (this=0x86b5e08, aResult=0xbfffa3f8) at nsCompositeDataSource.cpp:232 #10 0x4048322d in RDFGenericBuilderImpl::CreateContainerContents ( this=0x86db370, aElement=0x87e0198, aResource=0x871c370, aNotify=0) at nsRDFGenericBuilder.cpp:2318 #11 0x40479d7d in RDFGenericBuilderImpl::CreateContents (this=0x86db370, aElement=0x87e0198) at nsRDFGenericBuilder.cpp:741 #12 0x4047a88a in RDFGenericBuilderImpl::RebuildContainer (this=0x86db370, aElement=0x87e0198) at nsRDFGenericBuilder.cpp:902 #13 0x4049e8fb in nsXULDocument::RebuildWidgetItem (this=0x87194a8, aElement=0x87e0198) at nsXULDocument.cpp:3740 #14 0x40495567 in nsXULDocument::AttributeChanged (this=0x87194a8, aElement=0x87e0198, aNameSpaceID=0, aAttribute=0x82b1398, aHint=-1) at nsXULDocument.cpp:1184 #15 0x4047282c in nsXULElement::SetAttribute (this=0x87e0198, aNameSpaceID=0, aName=0x82b1398, aValue=@0xbfffaa98, aNotify=1) at nsXULElement.cpp:2145 #16 0x4046e300 in nsXULElement::SetAttribute (this=0x87e0198, aName=@0xbfffab30, aValue=@0xbfffaa98) at nsXULElement.cpp:1003 #17 0x404b8265 in nsXULTreeElement::SetAttribute (this=0x8665330, aName=@0xbfffab30, aValue=@0xbfffaa98) at nsXULTreeElement.h:51

I tried this on windows, and nothing bad happened. Exactly what are the steps to cause the problem? Or is this linux only?

I can't get address book to work at all on Linux. new card does nothing. My list of address books doesn't include the history address book, but rather, two personal address books. I can't make any progress on this bug without some sort of functionality working. Does this work for anyone else?

I tried Linux 1999111709-M12 build. On the new card create window or card editing window, there is a scrollable text window overlapped, and it covered some fields. But adding a new card or editing a existing card still works except that you can't change the fields that are covered. The problem described in this report was originally observed with 1999110408 linux build. But it is not repro anymore.

The duplicate address books in the left pane has been around for a while. The history address book only shows up if you read some mail, but it is working for me.

bienvenu: I was able to reproduce this (on Linux only) with a build from last night -- witness stack trace :-). And yes, address book is ugly as sin on Linux: text fields seem to be pretty much randomly sized.

morkTableRowCursor* // morkTable.cpp line 727 morkTable::NewTableRowCursor(morkEnv* ev, mork_pos inRowPos) { morkTableRowCursor* outCursor = 0; if ( ev->Good() ) { nsIMdbHeap* heap = mTable_Store->mPort_Heap; morkTableRowCursor* cursor = new(*heap, ev) morkTableRowCursor(ev, morkUsage::kHeap, heap, this, inRowPos); if ( cursor ) { if ( ev->Good() ) outCursor = cursor; else cursor->CutStrongRef(ev); } } return outCursor; } mPort_Heap in a store instance must not be null; this is a catastrophic failure, and probably has a provenance similar to other catastrophic errors. Note I don't check for null in a paranoid fashion here although I tend to do so throughout Mork code, even though folks think it's better architectural style to simply crash instead of asserting when such invariants fail in non-debug code.

I have a bunch of changes in my tree; should I dump them in? The tree looks open, but is it really open? I don't have clear bug numbers associated with my changes and having someone code review most things would mean nothing to them. The last paragraph indicates my tree doesn't exactly correspond to the one that is failing in this bug, and I can't just check in little twiddling changes to do what I'd normally do, which is put in additional paranoid null checks so the proximate cause of the catastrophic failure gets put into a smaller scope. Also, I'm not easily able to follow prescribed clean room rules for tree checkin. This is all FYI, and not a request for approval for a specific course of action.

I think we should figure out what horrible thing is leading to the null heap - I suspect other horrible things would happen as well. The build with the problems I described was from this morning - I tried deleting my address books and restarting, but it didn't help.

My edit card and new card window are opening up with 0 size - when I shut down the app, they pop up with just the little window icon, but I can't see them until shutdown time. I've tried deleting my localstore.rdf.

This can happen if you have merge conflicts in a XUL file, or if an overlay, script, or DTD file failed to load.

I'm on the tip re the xul files; I don't see any error messages, I did a clean build, and once I'm in this state, I can't even launch a new browser window or composer. Once I open the address book, I can't open any other windows. I can start with the browser, however.

Damn. I updated my build this morning and am now completely unable to reproduce the problem. I wonder if it's just random memory corruption? Sunspots? JS changes? Maybe we should pull out Purify on this one and see if anything evil is happening.

I can Purify (on NT) at home tonight.

I ran purify on NT, nothing suspicious. I tried most of the day to reproduce this, and couldn't. Please re-open if anyone sees this again.

The original bug as stated is working on linux with build 1999112008, I also retested Win32 and Mac and they are still OK regarding this original bug. Other items mentioned in this bug are duplicate address books (see bug 17680) and history address book not created at first (see bug 18476). I'm not seeing what was mentioned on 11/18/99 09:49 (but I did see it on 11/17 build). I'm not seeing what was mentioned on 11/18/99 13:52. I'm not seeing what was mentioned on 11/18/99 16:38 (however I did see this with the 11/19 build). Note: I am now crashing (Linux only) after Deleting a Card then reopening Abook in same session, I will log a new bug for that rather than reopen this one.