Closed Bug 826494 Opened 11 years ago Closed 11 years ago

Massive memory leak after opening message compose window in TB 17/18

Categories

(Thunderbird :: Message Compose Window, defect)

17 Branch
x86
Windows 7
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 818607

People

(Reporter: 611, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [regression:TB17])

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

This is a huge issue since Thunderbird 17 and I'm not sure why no one has reported it yet: When replying to or composing new emails, i.e. opening the message compose window and closing it afterwards (either manually or automatically when sending the email) not all of the memory allocated for the compose window is freed. This behavior can be observed in Windows Task Manager.

After doing this a couple of times (e.g. responding to a few emails), you will notice a massive memory leak. The longer you do this the more memory is being used by the Thunderbird process and the slower TB gets in addition (when selecting messages, clicking the Reply button, composing a message, clicking the Send button, everything). In fact, if you are like me and send dozens of emails, TB shortly gets so slow that it needs to be restarted. After sending 50-100 emails memory usage is at about 300-400MB, which gives you an idea of how massive this memory leak is.

This has been reproduced on two different machines (one very weak notebook with Windows 7 32-bit and another quite strong/new notebook with Windows 7 64-bit). No addons were used. It started with TB 17.0 and is still present in TB 18.0b1. I'm currently using TB 16.0.2 again and it runs perfectly fine without any such memory leak or slowdown.

I really hope the cause of this issue can be identified and fixed quickly as TB has become a real pain to use for me because of this.
Severity: normal → major
Severity: major → critical
Bug 814651 may be relevant.
  That bug started to occur from 2012-07-31-03-10-44-comm-central build.
  Change by bug 777063 is perhaps relevant to that bug.
  bug 777063 itself doesn't touch "re-use of composition window".
  Phenomenon of "composition window is not cached" is not by intentional change.
  Because of non-intentional, some resources may not be freeed upon window close.

> It started with TB 17.0 and is still present in TB 18.0b1.
> I'm currently using TB 16.0.2 again and it runs perfectly fine without any such memory leak or slowdown.

Same reression window as bug 814651 comment #29?

Another concern is "Add-on".
Do you see your problem with add-on disabled? (thunderbird.exe -safe-mode)
Do you see your problem even with newly created Tb's profile with minimum account definition? (for example, "Local Folders" only)
> Do you see your problem with add-on disabled? (thunderbird.exe -safe-mode)

As I said, no addons were used. Yes, this issue happens in safe mode as well.

> Do you see your problem even with newly created Tb's profile with minimum
> account definition? (for example, "Local Folders" only)

Yes, same issue on a completely new profile.
Whiteboard: Dupeme?
Severity: critical → major
Version: 18 → 17
611, how much memory do you lose per each compose window session?
Flags: needinfo?(611)
Whiteboard: Dupeme? → [regression:TB17]
Depends on: 480843
Closing as dup of bug 818607.
If duping is wrong, reopen with data for problem analysis of your case, with detailed description about difference of your case, please.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
No longer depends on: 765074, 820427
Flags: needinfo?(611)
You need to log in before you can comment on or make changes to this bug.