Closed Bug 818448 Opened 12 years ago Closed 11 years ago

lightning add-on in thunderbird bloats Explorer.exe memory size to several GB

Categories

(Calendar :: Lightning Only, defect)

Lightning 1.9
x86_64
Windows 7
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: christianstemmer, Unassigned)

Details

(Keywords: perf)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Build ID: 20121128204232 Steps to reproduce: lighning 1.9. is used as an add-on in thunderbird 17.0.1 I notice that Explorer.exe (Win 7 Pro) is using an increasing amount of memory (up to more than 2 GB over time). I have turned off all sevices in msconfig (see http://answers.microsoft.com/en-us/windows/forum/windows_7-performance/memory-leak-in-explorerexe/94abd6b5-e7c1-4832-b9f4-32eae6ed0270) which didn't solve the problem. After some trial and error, I noticed that the memory increase happens only when thunderbird is running. Deactivating all add-ons but ligthning1.9 confirmed the culprit. Re-installation of the add-on didn't work. The problem came with the update to Thunderbird 17.0.1 from 17.0 last week. Any more information needed ? Actual results: memory usage of Explorer.exe start slowly increasing step by step to several GB which renders the computer slow and difficult to put in hibernation mode. Expected results: Explorer.exe after startup takes about 30 MB space. Should stay in the range after opening of a single program.
Component: General → Lightning Only
OS: All → Windows 7
Hardware: All → x86_64
The Windows-Explorer adds about 260kb every 2-5 seconds to the used memory (if that helps). If I stop the explorer and start from new, the piling starts again (not difference to starting thunderbird after the explorer). Don't know which other tests I could do.
I can confirm this, it's terrible and once the "Private Bytes" hits around 2Gb (I have 8Gb memory and I'm not running out; probably hitting a cap on some resource/pool type) the windows shell stops responding. Currently running programs still work but I can't launch new ones, the start menu won't open, etc. I don't see a problem with just Thunderbird alone. Lightning does not have any binary components so whatever is leaking could well be a problem with our core windows interfaces (widgets?). I also see a slight constant memory growth in explorer.exe using just Firefox (Nightly and Aurora), possibly worse if you've got a lot of tabs and/or windows open. Hard to tell because it's slow, but I did hit a pretty high memory use on a day I explicitly avoided Thunderbird while trying to track down the culprit. I suspect this is an issue in the core Platform and Lightning simply does a lot of whatever it is. May not affect everyone, but whoever it does affect is not going to put up with having to restart windows several times a day.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh, should mention that I've seen the problem both with Thunderbird 19 (beta) and Lightning 2.whatever-was-compatible-beta as well as after downgrading to release Thunderbird 17.0.2 and Lightning 1.9
Lightning does have a binary component: calbasecomps.dll / libcalbasecomps.so / libcalbasecomps.dylib.
So it does, thanks. Guess I skimmed the directory listing too fast. Not sure that entirely lets core Gecko off the hook: running Firefox alone my explorer.exe memory has gone from 200Mb to 700Mb in the last hour. Not a quick death like Lightning, but still something's leaking. Could be two separate leaks, of course.
(In reply to Daniel Veditz [:dveditz] from comment #5) > So it does, thanks. Guess I skimmed the directory listing too fast. > > Not sure that entirely lets core Gecko off the hook: running Firefox alone > my explorer.exe memory has gone from 200Mb to 700Mb in the last hour. Not a > quick death like Lightning, but still something's leaking. Could be two > separate leaks, of course. Can't think of much except maybe our taskbar integration. Is this on Win 7? You could try disabling jump lists and taskbar previews to see if it helps. In about:config, search for "taskbar".
I have set the following parameters to FALSE mail.taskbar.lists.enabled mail.taskbar.lists.tasks.enabled These are the only ones that seemed to be relevant. The problem persists.
is this perhaps bug bug 833720 (swag because I haven't read all the comments)
Severity: normal → major
Keywords: perf
Dear Wayne, thanks for your idea - I don't see the number of threads increase. To deactivate all calendars doesn't help either (up to the point where not a single calendar has a check mark and still explorer.exe-memory usage keeps growing).
(In reply to Daniel Veditz [:dveditz] from comment #5) > So it does, thanks. Guess I skimmed the directory listing too fast. > > Not sure that entirely lets core Gecko off the hook: running Firefox alone > my explorer.exe memory has gone from 200Mb to 700Mb in the last hour. Not a > quick death like Lightning, but still something's leaking. Could be two > separate leaks, of course. In a week or two it may be worth checking the beta or next ESR, where bug 833720 should be fixed.
Dear Wayne, I am now on ESR 17.0.5 for a few weeks - the problem persists. Now - the maximum memory Windows Explorer grabs is just above 1GB. The problem is that the Explorer (not the internet one) hangs up once it's reached the maximum. Then I have to start from anew - it takes about 10-15 minutes to reach the 1GB+ limit.
Hy folks, as of the latest release ESR-17.0.7, the problem seems to have been resolved. Explorer is at ~70MB constantly. Checking my (7) mail accounts does not change the memory usage of Windows Explorer any more. Thanks a lot for looking at this issue - it really is more fun not to have to restart the explorer several times a day! Have a nice holiday weekend! Christian
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
It's happening again to me. Up to date Windows 7 Pro 64bit + up to date Thunderbird+Lightning+Google provider for Calendar. I've tried with beta 38.0 with same result.
You need to log in before you can comment on or make changes to this bug.