(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #331914 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=331914 Imported into Bugzilla on 02/04/99 16:36) When I search through "local mail" for a message, the VM space in my application grows by many megabytes. When close the search window and the related folder windows, the VM size does not decrease. After several searches, Communicator was using over 100 Megabytes of VM and was misbehaving (probably out of memory). I downloaded the US version of 4.5 off of the external web site today, and reproduced the problem with that version. I searched for messages with date after 9/26/98, sender contains netscape.com and body contains dejanews. My folders total 87 megabytes (including txt and .snm files).

Ouch. Asigning to Phil.

adding myself to cc: list.

I've been playing with this a little, and I do see VM growing a couple megs sometimes when searching, but not always. Purify doesn't report substantial leaks or memory in use, so I'm not sure what this memory is being allocated for. Will keep looking into it.

Doesn't meet marek's 4.51 criteria. TFV 5.0

Don't know who's doing Search for 5.0 yet. Accepting bug to myself to shut up terry's bugzilla notification bot.

won't be fixed for a while, since search is not implemented yet.

changing platform from PC to All since this bug, if still exists, would need to be checked on all platforms. Change QA contact to Suresh since he can verify the bug, once fixed.

Search won't be implemented in Beta 1, so this bug does not need to be fixed until after Beta 1

Search won't be implemented in Beta 1, so this bug does not need to be fixed until after Beta 1

mscott owns the search backend for 5.0, so reassigning to him for M14

this bug is on the "Most Frequent Bugs" page on http://www.mozilla.org/quality/most-frequent-bu gs/ which makes no sense because we don't even have a search front end. Send mail to leger to get it off

It'll be off in the next update ;-) Gerv

Killing off this bug as invalid for seamonkey. We are re-writing our search backend in 6.0. We may introduce a new big memory leak but we probably won't have the same big memory leak this bug would be pointing at.

Marking verified (invalid)