Closed Bug 491130 Opened 16 years ago Closed 16 years ago

Eudora 8b6 (TB3.0b2) with several hundred mailboxes and .msf files: hangs on compacting and building .msf files, searches fail, high file handle count, message “can’t load impab.mab”

Categories

(MailNews Core :: Backend, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: lester, Unassigned)

References

Details

(Keywords: hang, perf, regression)

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2) Build Identifier: version 8.0b6 See "steps to reproduce" Reproducible: Always Steps to Reproduce: 1. Use Eudora for 15 years, accumulating 220,000 messages and 2100 mailboxes. Observe while Eudora becomes Eudora Classic. Use Windows XP Pro SP3, POP3 exclusively. 2. On 13 March 2009, install Eudora8b5. Run with little trouble. 3. On 14 April 2009, upgrade to Eudora8b6. 4. Use for a few days. 5. Note that, with increasing frequency (now 100%), Eudora opens with errors “can’t load impab.mab”. Note that Eudora has opened 720-850 handles. Microsoft Process Explorer shows that most of those handles are an apparently random subset of mailbox and msf files at the beginning of the alphabet. Note that Eudora forgets its state upon exiting, hangs in compacting or constructing msf files, and generally becomes obnoxious. 6. Perform a search for subject containing “xxx” in Local Folders. No hits. Watch with relief while this operation drops Eudora’s handle count drops ~280. Smile while Eudora runs well. Do my day job. 7. Exit Eudora. 8. Restart Eudora. Return to lugubrious step 5; cure with step 6. Remain in loop. Actual Results: see "steps to reproduce" Expected Results: see "steps to reproduce" While compiling symptoms I have noted that a. Eudora never allows more than ~800 msf files. If I click on a mailbox to construct > ~800 msf files, these exist till the next restart. Then Eudora deletes all but ~550 msf files. b. The following strategems provide no relief. Unclick “for fast searching, allow Indexing Services to Index this folder (and subfolders)” for “local folders”. Inactivate X1. Inactivate antivirus software. Increase the cache from the default 50 MB to 100 MB. Delete all squlite files. c. Deleting all MSF files provides only temporary relief. As I work with more mailboxes and generate more msf files, I also generate more handles, eventually looping back to lugubrious step 5. d. Temporarily removing ~ 60% of mailboxes drops the file handle count to ~411 and allows Eudora to run. e. Peculiarities of my Eudora files. Many of my messages are subject to bug id=471399, and I have not tested for interaction with the present bug. f. ~250 of my folders show up in the folder pane with unread messages. This is correct. Conclusion: I am beginning to conclude that Eudora 8b6 has a hitherto unreported major bug in scaling to large numbers of mailboxes and messages. My results cannot be explained by one or a few “bad” messages or msf files. I'm considering this bug "critical" because only a person (yrs truly) who started writing machine-language code in 1963 could have persisted to find workaround #6. No data lost (yet).
#6 should read, "Watch with relief while this operation drops Eudora’s handle count to ~280."
There are no locked files in my profile
add to b (ineffective tactics): "Delete panacea.dat, XPC.mfl, or XUL.mfl".
add to b (ineffective tactics): Make new profile; move in only mail files, not msf's.
add to b (ineffective tactics): Move profile to the root directory. add to b(ineffective tactics): Reinstall Eudora8b6
Problems also occur, exactly as described, when I use Thunderbird 3b2. It's a TB bug (hopefully not drug-resistant)! Matt pls advise on which earlier TB release to try.
My suspicion is that this has to do with the new message indexer that was recently added to Thunderbird (and thus to Eudora). You can disable (I think) the indexer in the settings (Advanced->General->Enable Global Search and Indexer). Uncheck that to see if the problem goes away. Alternatively, I suggest you revert to Eudora 8.0.0b5 (http://eudora.com/download/eudora/8.0.0b5/Eudora-8.0.0b5.en-US.win32.installer.exe). Please let me know what you find. Matt
Reverting to Eudora 8b5 solves the problem; thanks. Will use this Eudora8b5 the bug gets fixed. (Reverting to Thunderbird 2 also solves the problem.) **However** unchecking the indexer in the Eudora 8b6 settings (Advanced->General->Enable Global Search and Indexer)**does not** work. My untutored, ignorant diagnosis arises from surfing various Thunderbird gloda (Global Search DAtabase) references and forums. I think that the parameter controlling global search has changed its name a couple of times and may vary among OS. Therefore I suspect that the UI for controlling this parameter has not caught up with these changes and is not, in fact, controlling the correct parameter. Don't know whether this is Tbird or Eudora. Thus there may be 2 interacting problems: (1) gloda malfunctions for > ~500 mailboxes, and (2) the UI controlling gloda malfunctions. I won't investigate this more thoroughly because of other time commitments. Your Thunderbird colleagues may wish to comment; I'll let you route this appropriately.
pls note that the "UI" I mentioned above is not the under-development gloda toolbar. It is the simple "options" dialog within Eudora and with Thunderbird.
Try setting "mail.winsearch.enable" to false You will need to add that to the settings (Advanced->General->Config Editor...) Matt
In Eurdora 8b6: mail.winsearch.enable is false mail.winsearch.logging.console is false mail.winsearch.logging.dump is falsle Yet the problem persists, precisely and completely as decribed. >700 handles, all but ~540 msf files get deleted. Eudora runs obnoxiously. Matt & I are both surpised. In Eudora 8b5, all is sweetness & light. I have retreated to Eudora 8b5, which has dutifully rebuilt my 2335 msf files during a "search" command. Repeating previous data: I have verified that this is a Thunderbird 3b2 problem and, indirectly via success with Eudora 8b5, that it does not occur in Thunderbird 8b1. I have verified directly that the problem does not occur in Thunderbird 2. Thunderbird developers, please acknowledge that you have read this bug.
Assigning to Thunderbird as this is not unique to Penelope.
Assignee: mozilla-bugs → nobody
Product: Penelope → Thunderbird
QA Contact: general → general
Target Milestone: --- → Thunderbird 3.0b2
Version: unspecified → Trunk
Matt: the target milestone field is for when you intend to land a patch for the bug, so given that b2 is in the past, it's an unlikely TM.
Target Milestone: Thunderbird 3.0b2 → ---
(In reply to comment #0) > > Conclusion: > I am beginning to conclude that Eudora 8b6 has a hitherto unreported major bug > in scaling to large numbers of mailboxes and messages. My results cannot be > explained by one or a few “bad” messages or msf files. correct Matt. not Penelope. and not gloda or indexer. most likely very bad regression of bug 469448, which is got out in Thunderbird 3.0b2, the release on which 8b6 is based. 469448 should be fixed in bug 481065. related: Bug 480848 - unresponsive script warning starting thunderbird folderPane.js:845 Bug 478595 - Crashes on launch Matt, we will want to determine lester does not see the problem in what will become 8b7
Blocks: 469448
Status: UNCONFIRMED → NEW
Component: General → Backend
Ever confirmed: true
Keywords: hang, perf, regression
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Summary: Eudora 8b6 hangs with many mailboxes → Eudora 8b6 (TB3.0b2) with several hundred mailboxes and .msf files: hangs on compacting and building .msf files, searches fail, high file handle count, message “can’t load impab.mab”
When so requested, I will test Eudora 8b7. Possibly unique aspects of my mail: imported from Eudora classic 7.1 by Eudora 8b6. 2250 mailboxes, nested 4 deep ~220,000 messages, dating from ~1994 6.37 GB Overlooked so far in this discussion: Eudora 8b6 and Tbird 3b2 actually **delete** all but ~500 msf files when started. Tha's why others have reported slow scrolling within the mailbox pane. Does not occur with Eudora 8b5. Would you like me to reinstall Tbird 3b1 and send you the error console screen shot? Of course, "If a computer were smart enough to give the correct error message, it would be smart enough to correct the problem itself, with an error message". Source? Yogi Berra, 1958.
oops, Yogi said, ". . . without an error message".
If so commanded, I will try 3b3pre. Takes but a few minutes. But pls assure me that all my reported problems ought, in principle, to be resolved by the fix.
(In reply to comment #17) > If so commanded, I will try 3b3pre. Takes but a few minutes. But pls assure > me that all my reported problems ought, in principle, to be resolved by the > fix. fantastic. Yes, it will be useful to know the results - far better to know now whether all are fixed, than to wait for 8b7 and possibly find some are not fixed while we are neck deep into shipping 3.0b3.
Should I try it now?
Good news. Shredder/3.0b3pre, downloaded today 5/9/09 as thunderbird-3.0b3pre.en-US.win32.installer.exe, seems to fix the problems that have transfixed this thread. To wit, a) Thunderbird opens ~244 handles. This is good. b) Thunderbird maintains all 2250 msf files and rebuilt a few during a search. This is good c) Thunderbird correctly performs a search that retrieves 1250 hits, scattered among mailboxes. This is good. Uncertainty: I did click "enable global indexer", but global-messages-db.sqlite has only 3.2 MB. The last time I deleted it in disgust (coupla weeks ago), it had ~350 MB. So I don't know whether this function works. I have retreated to Eudora 8b5 until the next Eudora beta (8b7) issues, presumably incorporating the bug fix in Thunderbird 3b3pre Thanks for the help and attention. **Please tell the Eudora team, & thank them for me, especially Matt**
nice. so let's call this WFM reopen if next release of Eudora fails
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.