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

VERIFIED WORKSFORME

Status

P1
critical
VERIFIED WORKSFORME
19 years ago
14 years ago

People

(Reporter: ji, Assigned: Bienvenu)

Tracking

Trunk
Other
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
QA Contact: lchiang → esther

Comment 1

19 years ago
ji - can you try this on Win32 as well?
(Reporter)

Comment 2

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

Comment 3

19 years ago
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?

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M12

Comment 4

19 years ago
Marking as M12, please change to M11 if needed.

Updated

19 years ago
Whiteboard: [PDT+]

Comment 5

19 years ago
Putting on PDT+ radar.

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] 11/12

Updated

19 years ago
Blocks: 18471

Updated

19 years ago
Summary: [DOGFOOD] Relaunching Address book after change leads to browser crash → [DOGFOOD] Relaunching Address book after change le1ads to browser crash

Comment 6

19 years ago
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.
(Reporter)

Comment 7

19 years ago
Checked again on M11 111017 and M12 111508 Linux build. The problem is gone.
Will wait latest M11 to check it again.
(Reporter)

Comment 8

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

Updated

19 years ago
Blocks: 18951

Updated

19 years ago
Assignee: hangas → waterson
Status: ASSIGNED → NEW

Comment 9

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

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Whiteboard: [PDT+] 11/12 → [PDT+]

Comment 10

19 years ago
looking...

Updated

19 years ago
Priority: P3 → P1

Updated

19 years ago
Summary: [DOGFOOD] Relaunching Address book after change le1ads to browser crash → [DOGFOOD] Relaunching Address book after change leads to browser crash

Updated

19 years ago
Assignee: waterson → bienvenu
Status: ASSIGNED → NEW

Comment 11

19 years ago
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
(Assignee)

Comment 12

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

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 13

19 years ago
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?
(Reporter)

Comment 14

19 years ago
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.

Comment 15

19 years ago
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.

Comment 16

19 years ago
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.

Comment 17

19 years ago
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.

Comment 18

19 years ago
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.
(Assignee)

Comment 19

19 years ago
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.
(Assignee)

Comment 20

19 years ago
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.

Comment 21

19 years ago
This can happen if you have merge conflicts in a XUL file, or if an overlay,
script, or DTD file failed to load.
(Assignee)

Comment 22

19 years ago
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.

Comment 23

19 years ago
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.
(Assignee)

Comment 24

19 years ago
I can Purify (on NT) at home tonight.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 25

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 26

19 years ago
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.

Updated

19 years ago
No longer blocks: 18471

Updated

19 years ago
No longer blocks: 18951
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.