Closed Bug 94585 Opened 23 years ago Closed 23 years ago

Hang and crash trying access large address book

Categories

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

Product:
SeaMonkey
Component:
MailNews: Address Book & Contacts
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.8

People

(Reporter: olgac, Assigned: cavin)

References

Details

(Whiteboard: nab-ab,nab-imp) 

Steps to reproduce:

1. Create really big Address book.
    E.g., download netscape corporate address book using 4.x, convert it
    to mork DB using  Task->Tools->Import Utility. You'll get .mab file ~16MB
2. In N6 bring up Address Book
3. In the left pane of  the AB window select that big AB

Results: hang, and in about 20 min crash 

I got the crash on 2001080609 trunk build. Tried on 2001072309 trunk build also
to make sure this is not MAPI AB integration regression and still got the crash.

The crash kills msvc, so the only stack trace available is from Talkback:

Incident ID 33857742
Stack Signature awt.dll + 0x5220e (0x5007220e) 73139e9f
Bug ID
Trigger Time 2001-08-08 12:54:26
Email Address olgac@netscape.com
User Comments
Build ID 2001080609
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Access violation
Stack Trace
awt.dll + 0x5220e (0x5007220e) 

and

Incident ID 33874722
Stack Signature nsStr::EnsureCapacity 2d01b3ea
Bug ID
Trigger Time 2001-08-08 16:33:46
Email Address olgac@netscape.com
User Comments
Build ID 2001072309
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Access violation
Stack Trace
nsStr::EnsureCapacity [d:\builds\seamonkey\mozilla\string\obsolete\nsStr.cpp,
line 107]
Keywords: nsBranch
QA Contact: fenella → nbaca
Blocks: 99230
MScott - Is this nsbranch+ worthy?
No longer blocks: 99230
per pdt triage. could this be done soon? we don't want to wait for the first
enterprise escalation on this one
Keywords: nsbranch → nsbranch+
I download 8600+ cards from AOL ldap server anf export to ldif file.  Imported
to my debug build on win2000 and didn't get a crash.  The .mab file is about 18
MB.  It did took a while (20 sec.) to display the cards.  My tree ws updated
yesterday.
Olga, can you retest this on Monday against a branch build? Candice thinks this
may be working now. Thanks!
olga charapaev doesn't show up in the Netscape phone book. nbaca - can you see
if this is reproducible?

jpatel/shiva - is this a topcrash on talkback for 094?
Whiteboard: PDT
Lisa: I just did a quick search for nsStr::EnsureCapacity and didn't find too
many crashes for M094 (only 7 incidents on Linux).  However, it did seem to be a
topcrasher for Mozilla 0.9.3, so perhaps this crash was fixed at some point
after that release?  

There were a lot of crashes with build 2001080104 MozillaTrunk  (Mozilla 0.9.3
on Linux 2.2.16) and a few others with build  2001080112 MozillaTrunk (Mozilla
0.9.3 on Windows).

About the awt.dll crash, there were a few crashes like this one for Netscape
6.10, but only a couple of recent incidents.



Branch build 2001-09-26-05: WinMe

I have 4 ldif files with the following number of addresses:
1. 10,000
2. 20,000
3. 30,000
4. 40,000

After importing these ldif files, here are the results:
a.  In all cases, the import process works as expected.

b. After selecting the address book in the left pane, the following successfully
displays the addresses: 
- 10,000 address cards: 2 minutes before addresses displayed
- 20,000 address cards: 3 minutes before addresses displayed
- 30,000 address cards: 5 minutes before addresses displayed

c. After selecting the address book in the left pane, the following hangs the
application:
- 40,000 address cards: I waited atleast 10 minutes, was unable to access the
3pane, Browser or move the Address book window.
Additional Notes: 
After successfully viewing address books with 20,000 and exiting the application
I noticed alot of cpu activity. 

Closing out of the Address Book with 30,000 appears to hang the application
since the address book window doesn't close and still cpu activity continues.
Had to Ctlr+Alt+Del to end the process. I started the application again to view
the 30000 cards, after a File|Exit it exited more gracefully because the windows
closed but the cpu continues.
When the cpu continues, even after appearing to exit because all the application
windows are closed, I have to Ctrl+Alt+Del and end the NS6 process.
Whiteboard: PDT → [PDT]
I'm minusing this for the branch. I don't believe 20 thousand address book
entries is going to be common and we don't have any resources for the address
book right now. We're still trying to figure out whose going to work on it going
forward.
Keywords: nsbranch+ → nsbranch-
Target Milestone: --- → mozilla0.9.6
reassigning to cavin
Assignee: chuang → cavin
moving to 1.0.  I'm wondering if this would benefit from the outliner rewrite,
given that we used to have similar problems (of taking a long time and seeming
like it was hanging) in mail with large folders.
Target Milestone: mozilla0.9.6 → mozilla1.0
Removing [PDT] grafitti because this was minused by component team.
Whiteboard: [PDT]
Blocks: 107067
Keywords: nsbranch-
The results from 9/26/2001 are the same if I migrate a profile with large
address books.
Ninoschka, could you try this on one of Seth's AB outliner builds?  I hope the
problem goes away.
Keywords: nsbeta1
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 113771 has been marked as a duplicate of this bug. ***
AB-Outlinder build from 12/7: Wow, what a difference. 

4.7: With 10,000 cards in my ldif file it took about 8 minutes to import the 
cards. 
AB-Outliner: It took about 30 seconds! (fyi: scrolling is fast, seeing the 
contents of a card is fast, was able to copy 2,000 cards without a crash).
Adding Seth and Dan to see the good news.  I'm moving the bug in since large
addressbooks are important when dealing with ldap replication.
Target Milestone: mozilla1.0.1 → mozilla0.9.8
yes, we should be better at handling big files after I land the branch.

as far as blocking the UI, I don't think importing a large AB (.na2, .txt, .tab,
.csv, .ldif) will block the UI, since the import code does run on another thread.

I'm not sure it yields to the UI thread.  If not, we can easily fix it.

but opening a large .mab file [when you first autocomplete against it, bad idea,
but it could happen, or when you select it in the addressbook window] we will
block the UI, as that code takes over the UI thread.

cavin / dmose / bienvenu and I can meet and discuss more, after the
AB_OUTLINER_BRANCH lands.
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P1
Whiteboard: nab-ab
Whiteboard: nab-ab → nab-ab,nab-imp
Running the 01-10-02 commercial build, here are the test results  (in seconds) 
from importing various large address books:

  10K       20K       30K
 -----     -----     -----
 16.87     35.21     61.11

and here are the numbers (in seconds) to open each of the imported addressbook:

  10K       20K       30K
 -----     -----     -----
  1.73      2.72      3.83

The only comment I have here is that we should turn on the busy cursor when 
opening an addressbook.

In addition, I was able to copy 5,245 cards to another addressbook without 
problem, though it took 45 seconds. Again, we should probably turn on the busy 
cursor here.

Scrolling is very fast/smooth. Searching for 11 out of 30K cards (ie, search 
string is "FN2996") took about 5.3 seconds from the time I stopped typing any 
char and is about 3.8 seconds for the 20K addressbook.

The UI thread is not blocked when importing addressbooks.

Let me know if there are things I should also test/try, but from my tests 
importing addressbooks seems to be working great.
The above numbers to open addressbooks were taken right after the addressbooks 
were imported. If you restart the mail app and then open the addressbooks the 
numbers are a bit higher:

  10K       20K       30K
 -----     -----     -----
  2.34      5.61     11.04
Cavin: what sort of machine (eg speed, ram, OS, etc) were you testing on?
My machine is a 650 MHz laptop from Dell running winnt (with 256 MB memory).
marking worksforme based on comments.  Seth has already filed another bug on
trying to improve loading AB's.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Verified Worksforme (there are actually other bugs that cover problems when 
loading large address books).
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.