Closed Bug 17988 Opened 25 years ago Closed 25 years ago

[DOGFOOD] Relaunching Address book after change leads to browser crash

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Address Book & Contacts
Platform:
Other
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: ji, Assigned: Bienvenu)

Details

(Whiteboard: [PDT+]) 

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.
QA Contact: lchiang → esther
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?
Status: NEW → ASSIGNED
Target Milestone: M12
Marking as M12, please change to M11 if needed.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Whiteboard: [PDT+] → [PDT+] 11/12
Blocks: 18471
Summary: [DOGFOOD] Relaunching Address book after change leads to browser crash → [DOGFOOD] Relaunching Address book after change le1ads to browser crash
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.
Blocks: 18951
Assignee: hangas → waterson
Status: ASSIGNED → NEW
Chris, this is the crasher we talked about earlier.  Sending to you...  Thanks.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] 11/12 → [PDT+]
looking...
Priority: P3 → P1
Summary: [DOGFOOD] Relaunching Address book after change le1ads to browser crash → [DOGFOOD] Relaunching Address book after change leads to browser crash
Assignee: waterson → bienvenu
Status: ASSIGNED → NEW
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?
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → VERIFIED
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.
No longer blocks: 18471
No longer blocks: 18951
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.