Hang and crash trying access large address book

VERIFIED WORKSFORME

Status

SeaMonkey
MailNews: Address Book & Contacts
P1
normal
VERIFIED WORKSFORME
17 years ago
13 years ago

People

(Reporter: olga charapaev, Assigned: Cavin Song)

Tracking

Trunk
mozilla0.9.8
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nab-ab,nab-imp)

(Reporter)

Description

17 years ago
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]

Updated

17 years ago
Keywords: nsBranch

Updated

17 years ago
QA Contact: fenella → nbaca

Updated

16 years ago
Blocks: 99230

Comment 1

16 years ago
MScott - Is this nsbranch+ worthy?

Updated

16 years ago
No longer blocks: 99230

Comment 2

16 years ago
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+

Comment 3

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

Comment 4

16 years ago
Olga, can you retest this on Monday against a branch build? Candice thinks this
may be working now. Thanks!

Comment 5

16 years ago
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

Comment 6

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


Comment 7

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

Comment 8

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

Comment 9

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

Updated

16 years ago
Whiteboard: PDT → [PDT]

Comment 10

16 years ago
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

Comment 11

16 years ago
reassigning to cavin
Assignee: chuang → cavin

Comment 12

16 years ago
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

Comment 13

16 years ago
Removing [PDT] grafitti because this was minused by component team.
Whiteboard: [PDT]

Updated

16 years ago
Blocks: 107067

Updated

16 years ago
Keywords: nsbranch-

Comment 14

16 years ago
The results from 9/26/2001 are the same if I migrate a profile with large
address books.

Comment 15

16 years ago
Ninoschka, could you try this on one of Seth's AB outliner builds?  I hope the
problem goes away.
Keywords: nsbeta1

Comment 16

16 years ago
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

Comment 17

16 years ago
*** Bug 113771 has been marked as a duplicate of this bug. ***

Comment 18

16 years ago
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).

Comment 19

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

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P1

Updated

16 years ago
Whiteboard: nab-ab

Updated

16 years ago
Whiteboard: nab-ab → nab-ab,nab-imp
(Assignee)

Comment 21

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

Comment 22

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

Comment 24

16 years ago
My machine is a 650 MHz laptop from Dell running winnt (with 256 MB memory).

Comment 25

16 years ago
marking worksforme based on comments.  Seth has already filed another bug on
trying to improve loading AB's.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 26

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