Closed Bug 94585 Opened 24 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.