818607 - Memory leak when Message Compose Window is opened and actually closed by Send or Send Later (memory leak is observed when compose window is not cached/recycled)

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Petr Vones]

Steps to reproduce (all addons and plugins disabled, message bodies are plain text only)

1. switch to Inbox folder
2. select a message
3. click Reply button
4. close message compose window

Repeat steps 3 to 4 multiple times.

The amount of memory (VM Size column in Task Manager) increases everytime the message compose window is shown. Typically it is about 100 MB on start, after repating the steps 3 and 4 about 20 times its over 170 MB and slows down typing in message compose window.

Comment 1

[Petr Vones]

Might be related to bug 765074 but the issue has become more visible and irritating in TB 17.0

Comment 2

[Petr Vones]

The impact of the issue is actually even worse. When the allocated virtual memory is about 170 MB, TB process CPU utilization goes up to 50% in regular intervals (maybe a GC issue) and have to be restarted.

The user case is simple, I usually Edit/Save/Close a new message multiple times before sending.

Comment 3

[Wayne Mery (:wsmwk)]

Petr, is this with both plain text and rich text compose window?

I was not able to reproduce a couple days ago. I can't remember if I tried both compose types.

Comment 4

[Petr Vones]

I use plain text only in Compose Window and have selected View | Message Body As -> Plain Text.

I can reproduce it on multiple machines, all of them have similar settings: plain text everywhere.

Comment 5

[Wayne Mery (:wsmwk)]

Does it also happen if you have started in safe mode?

I can't reproduce. memory goes up, but then comes back down.

Comment 6

[Petr Vones]

Yes, it happens in safe mode as well. Steps to reproduce:

1. Create new plain text message and save it in Drafts folder
2. Select the message in Message pane (to edit it by pressing Enter key)
3. Press Enter to edit the message
4. Press Alt+F4 to close Message Compose Window
5. Repeat steps 3 to 4 at least 20 times or more

I attached screenshot from Performance monitor. It starts after a Message Compose Window has been opened first time (about 96M) and ends after it has been opened/closed 20 times (about 135 MB). It never comes back down.

Comment 7

[Petr Vones]

Attachment: Thunderbird memory leak graph

Comment 8

[Wayne Mery (:wsmwk)]

Petr, would you say this is a regression, and if so when/what version did it start occurring?


I can reproduce this with current daily in safe mode.  Lose approximately 2MB per opening of compose simply by doing ctrl+N to create new message and ctrl+W, no other steps or typing.

I would add, that I haven't been entirely happy lately with compose window performance.  It seems slightly sluggish.

related to rkent's bug 820427?

Comment 9

[Wayne Mery (:wsmwk)]

Attachment: memory usage before and after open+closes

Comment 10

[Wayne Mery (:wsmwk)]

there is also bug 765074 with bienvenu's patch

Comment 11

[Petr Vones]

I noticed it with 17.0 version first. I use Thunderbird since version 9.0.

Comment 12

[Wayne Mery (:wsmwk)]

Petr, can you check past version(s) to see when this started?
Perhaps start with 16 and work backward
https://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/

Comment 13

[Petr Vones]

The 16.0.2 version does not have the memory leak issue (safe mode, same steps) and the Message Compose Window is not that sluggish. It has started in 17.0 version.

Comment 14

[Petr Vones]

Attachment: Thunderbird 16.0.2 memory graph that shows there is no memory leak.

Comment 15

[Kent James (:rkent)]

I think that the issues mentioned in my bug 820427 have been around for a long time, so I doubt if those are the cause of what appears to be a recent regression.

Comment 16

[Wayne Mery (:wsmwk)]

Petr, thanks very much.

It will be helpful if someone can narrow the regression range range to a one day period so we can identify the offending patch that caused this.

probably want to first check 17.0a1 at the end of august https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/08/

if it exists there then we check the builds in a binary fashion between https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/07/2012-07-17-03-02-01-comm-central/ and the end of august.

Comment 17

[Petr Vones]

Actually it seems as the bug is there forever. I went back to version 7.0a1 (seven, not 17) and can reproduce it as well in safe mode (with addons disabled).

Note that with this addon https://addons.mozilla.org/en-US/thunderbird/addon/correct-identity/ enabled the memory leak did not happen until 17.0 version. That's why I haven't noticed it earlier because I use the addon from the beginning.

Comment 18

[Wayne Mery (:wsmwk)]

Petr, thanks for the update. If this is not a recent regression, then rkent's bug 820427 becomes a factor.  Are you game for trying version 5 and/or version 3.1?  :)

In my testing Daily in safe mode, I lose about 2MB per compose session. I set thunderbird offline. I lose about 2MB per compose session.
compose 114,744  
sent 110,668
compose  116,204 
sent  114,228
compose 118,764
sent 116,668

I did not test older versions.

xref bug 826494

Comment 19

[Petr Vones]

Version 5 ? No :-) The bug is present, easily reproducible (half win), affecting most users, so it is supposed to be fixed.

Comment 20

[:aceman]

So can you try the version from bug 765074 comment 29 ?

Comment 21

[rsx11m]

Err... Wayne reports there no change with that try-server build, so I don't quite see the point letting Petr test it?

Comment 22

[Wayne Mery (:wsmwk)]

(In reply to rsx11m from comment #21)
> Err... Wayne reports there no change with that try-server build, so I don't
> quite see the point letting Petr test it?

I have no way of knowing where my memory loss is coming from. So fwiw, i'd love to see someone else test it.

Comment 23

[:aceman]

Wayne reported improvement under some situations.

Comment 24

[Petr Vones]

(In reply to :aceman from comment #20)
> So can you try the version from bug 765074 comment 29 ?

Yep. The bug is still there, no improvement.

Comment 25

[Petr Vones]

Actually, there is an improvement but the behavior is rather weird and a bit random. I installed https://addons.mozilla.org/cs/thunderbird/addon/viewabout/ to display about:memory page. It is the only addon enabled for the test.

After TB is started the report is:

57.44 MB (100.0%) -- explicit
├──24.01 MB (41.81%) ++ js-non-window
├──18.48 MB (32.17%) ++ window-objects
├───7.63 MB (13.28%) ── heap-unclassified

The Message Compose Window test (new, close, repeat 20 times)

77.39 MB (100.0%) -- explicit
├──29.82 MB (38.53%) ++ js-non-window
├──26.01 MB (33.61%) ++ window-objects
├──13.03 MB (16.84%) ── heap-unclassified

Now you have to wait about one minute (pressing [GC]->[CC]->[GC] buttons immediately after the test does not help at all) and press [Update] button. It  goes down to:

52.59 MB (100.0%) -- explicit
├──26.19 MB (49.79%) ++ js-non-window
├───9.92 MB (18.85%) ++ window-objects
├───8.66 MB (16.46%) ── heap-unclassified

Comment 26

[:aceman]

That looks quite good. Can you confirm that with the old version you were using before, in measurement 3 (~1 minute after closing the windows) the memory did not go down, stayed at ~77MB ?

Comment 27

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #26)
> That looks quite good.

I could observe it too.
[Test procedure]
(0) Create mail-X-0 to mail-X-9 in Outbox of Local Folders by Send Later.
    mail.compose.max_recycled_windows=5 for test
    composition mode = HTML
(1) Restart Tb. Keep "Work Online" mode.
(2) At Outbox, select mail-X-0 to mail-X-N (N : 1 to 9, tested with N==5),
    Message/Edit Message As New,
    At each composition window, "Send Later"(change X in Subject to Y if needed)
(3) Repeat (2) several times.

[Quick observation result]
Note:
Quick Observation is by "Virtual Memory Size" column value of Win's Task Manager.
(A) Tb 17.0.2 on MS Win.
    "Virtual Memory Size increase" / "one repeat of (3)"
    == approximately 4MB increase / one repeat
(B) The Try server build on MS Win(win32.zip build).
    After first Compose/Send of step (2), Virtual Memory Size increases by the
    Compose/Send, and Virtual Memory Size won't be reduced to initial size.
       Initial Size after restart of Tb : V_0              ( where 0<V_0 )
       After first Compose/Send         : V_1 == V_0 + V_x ( where 0<V_x )
       Not returns to initial V_0 
    But by each repeat after it, following is observed.
      By Composition/Send Later : increases to V_1 + V_y (V_y : several to 10 MB)
      After a while : goes back to V_1 (not exactly same, but delta is small)
  
    Approximate Virtual Memory Size increase / one repeat of (3)
    == No increase / per one repeat
       (if leak like increase exists, far less than 1MB / repeat)

Comment 28

[:aceman]

If only the first compose window open causes some memory increase and the achieved level V_1 is then kept after any number of subsequent opens, I think that is fine and expected. I think there must be some caching of compiled JS code of the window kept by core JS engine. Maybe that will be released after more time.

Or there is still some other leak, but it is only once per session (TB open/close) in the range of 0-2MB as I said in bug 765074 comment 17.

Comment 29

[Petr Vones]

(In reply to :aceman from comment #26)
> That looks quite good. Can you confirm that with the old version you were
> using before, in measurement 3 (~1 minute after closing the windows) the
> memory did not go down, stayed at ~77MB ?

Yes. Similar test with current TB release 17.0.3

After start:

51.25 MB (100.0%) -- explicit
├──21.02 MB (41.02%) ++ js-non-window
├──12.35 MB (24.09%) ── heap-unclassified
├───9.87 MB (19.26%) ++ window-objects

The Message Compose Window test (new, close, repeat 20 times)

88.43 MB (100.0%) -- explicit
├──36.17 MB (40.90%) ++ window-objects
├──22.46 MB (25.40%) ++ js-non-window
├──18.71 MB (21.16%) ── heap-unclassified

After 5 minutes still no change:

90.28 MB (100.0%) -- explicit
├──37.64 MB (41.69%) ++ window-objects
├──22.64 MB (25.08%) ++ js-non-window
├──21.32 MB (23.62%) ── heap-unclassified

GC->CC->GC->Update no change either.

Comment 31

[611]

I previously reported this very bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=826494

I just tried TB 20.0b1 and found that this massive memory leak (which also slows down TB badly) still isn't fixed.

Hopefully someone will be able to finally fix this soon because due to this I'm stuck at 16.0.2 (which shows perfectly constant memory usage) for months. Newer versions have become totally unusable for me as I often send hundreds of emails in a single session.

As stated before this leak should be reproducible for anyone. An easy way is to quickly open and close the message compose window many times in a row.

Comment 32

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #31)
> I just tried TB 20.0b1 (snip)

Read "Target Milestone:" field of bug 765074 well, please.
If patch will be ported to Aurola or next Release, it'll be indicated by "Tracking Flags:" field of thet bug.

Comment 33

[WADA:World Anti-bad-Duping Agency]

Closing as FIXED with [Fixed by Bug 765074] in Whiteboard: field, because I think duping to that bug is not appropriate.
If it's wrong, correct it, please

Comment 34

[611]

Bug 765074 is now reported as fixed in TB 21, but I still get the memory leak in this version.

Comment 35

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #34)
> but I still get the memory leak in this version.

What kind of "memory leak"?
What is definition of your "memory leak"?

Absolutely same "memory leak" what reported to comment #0 of this bug?
If so, what is evidence that problem you still see is absolutely same problem as comment #0?

If you are are talking about "memry leak on MS Win", please read at least all documents pointed in bug 381950 before open bug relevant to "memory leak on MS Win" and before add comments about "memory leak on MS Win".

Comment 36

[611]

> What kind of "memory leak"?
> What is definition of your "memory leak"?
> 
> Absolutely same "memory leak" what reported to comment #0 of this bug?
> If so, what is evidence that problem you still see is absolutely same
> problem as comment #0?

The same memory leak that has been discussed here before (including comment #0), related to opening the message compose window. Memory usage in TB 16.0.2 doesn't increase even when opening/closing the window many times, but in TB 21 it keeps increasing without coming back down. There is also a noticable slowdown after a while as mentioned in my previous bug report (https://bugzilla.mozilla.org/show_bug.cgi?id=826494).

Again, reproduction is simple: Simply open and close the compose window repeatedly and check TB's memory usage.

Comment 37

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #34)
> Bug 765074 is now reported as fixed in TB 21, but I still get the memory
> leak in this version.

Which build? Following?
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/21.0b1-candidates/build1/
If so, patch is not landd on build1 yet.
  build1 : dated 09-Apr-2013
  Bug 765074 status-thunderbird21 fixed : 2013-04-09
             This means patch will be landed final release of Tb 21,
             doesn't mean patch landed on any build for Tb 21.
Because of release candidate, maintenance and build cycle is different from nightly.
Check with following nightly first, please.
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-earlybird/
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-aurora/
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-aurora/

Comment 38

[611]

(In reply to WADA from comment #37)
> (In reply to 611 from comment #34)
> > Bug 765074 is now reported as fixed in TB 21, but I still get the memory
> > leak in this version.
> 
> Which build? Following?
> > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/21.0b1-candidates/build1/
> If so, patch is not landd on build1 yet.
>   build1 : dated 09-Apr-2013
>   Bug 765074 status-thunderbird21 fixed : 2013-04-09
>              This means patch will be landed final release of Tb 21,
>              doesn't mean patch landed on any build for Tb 21.

Yes, that build. According to the changelog on http://www.mozilla.org/en-US/thunderbird/21.0beta/releasenotes/ the fix is already included in this version.

> Check with following nightly first, please.

I just tested the latest nightly build (Earlybird) and found the exact same behavior - not fixed.

Comment 39

[611]

I noticed that bug 765074 was reported for TB 13 in June 2012 which was long before TB 17 (where the massive memory leak being discussed here first started to appear) was released.

Therefore it seems like we are talking about two separate issues here.

Comment 40

[611]

Ok, I tried to investigate when exactly this memory leak started to appear and found the following:

- The last working nightly build (17.0a1) without the leak was on July 23, 2012 (https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/07/2012-07-23-03-06-06-comm-central/).

- All (!) the following nightly builds from July 24 to July 30 were crashing after opening the message compose window the 2nd time. This clearly indicates that starting July 24 (broken) code was added that changed the handling of this window.

- The nightly build on July 31 finally fixed the crashes but also started to show the memory leak.


I haven't mentioned that before, but the Windows 7 popup animation of this window when opening it for the 2nd and following times looks differently in the July-31 build than in the previous builds (before the crashes). This is a core difference between TB 16.0.2 and 17.0+ as well - in the old version the window pops up instantly (no real animation, as if it was already loaded in the background) whereas in the newer versions there is the typical new-window (fade-in) animation. That's probably related to window caching of some sort, which might also be responsible for this memory leak.

Either way, I hope the above analysis helps someone find out what exact changes submitted on these days introduced the memory leak.

Comment 41

[611]

WADA, I noticed your findings months ago match mine very well (regarding the July-31 build): https://bugzilla.mozilla.org/show_bug.cgi?id=826494#c1.

Comment 42

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #40)
> Ok, I tried to investigate when exactly this memory leak started to appear and found the following:
>(snip)
> - The nightly build on July 31 finally fixed the crashes
> but also started to show the memory leak.

Thanks for duplication test of bug 814651 comment #28 and for your finding regression window of this bug what started from Tb 17.

Large memory leak in comment #0 is not observed after fix of bug 765074, and transformation　of virtual memory size is same as comment #17 in trunk nightly(Thunderbird/23.0a1, 20130415030442 build).
However, "a few mega bytes VM increase" per "10 to 20 compose window open and close by Send Later" was stil oserved in my quick test.

Re-opening for analysis of regression of this bug started from Tb 17.

Comment 43

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #40)
> The nightly build on July 31 finally fixed the crashes
> but also started to show the memory leak.

It's build from which bug 814651 started to occur. i.e. Compose window is not cached from this build, instead is actually closed as done with mail.compose.max_recycled_windows=0.

I believe it started to expose large memory leak by problem of Bug 765074. I guess that large memory leak like commemt #0 can be observed even in Tb 17 /2012-07-23-03-06-06-comm-central/ build if mail.compose.max_recycled_windows=0. Is it right?

Comment 44

[WADA:World Anti-bad-Duping Agency]

FYI.
Following is copy of bug 777063 comment #31 from owner of bug 777063.
> there's a logic error in my patch, and compose windows no longer get recycled. 
> Once I've worked out a patch, I'll attach it to bug 814651.

Comment 45

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #40)
> I haven't mentioned that before, but the Windows 7 popup animation of this window
> when opening it for the 2nd and following times looks differently in
> the July-31 build than in the previous builds (before the crashes). > This is a core difference between TB 16.0.2 and 17.0+ as well
> - in the old version the window pops up instantly (no real animation, as if it was already loaded in the background)
> whereas in the newer versions there is the typical new-window (fade-in) animation.

It's perhaps a phenomenon of bug 814651;
- Before patch for bug 777063, compose window is cached and reused.
- After  patch for bug 777063, compose window is closed and not cached.

Comment 46

[611]

> I believe it started to expose large memory leak by problem of Bug 765074. I
> guess that large memory leak like commemt #0 can be observed even in Tb 17
> /2012-07-23-03-06-06-comm-central/ build if
> mail.compose.max_recycled_windows=0. Is it right?

Correct. The same is the case for 16.0.2.

Comment 47

[WADA:World Anti-bad-Duping Agency]

FYI.
Regression by bug 777063(Compose window is not recycled after Tb 17) is being processed by bug 866223. Until bug 866223 will be fixed, check with mail.compose.max_recycled_windows=0 to avoid confusion and misleading, please.

Comment 48

[611]

> Large memory leak in comment #0 is not observed after fix of bug 765074, and
> transformation　of virtual memory size is same as comment #17 in trunk
> nightly(Thunderbird/23.0a1, 20130415030442 build).
> However, "a few mega bytes VM increase" per "10 to 20 compose window open
> and close by Send Later" was stil oserved in my quick test.

I disagree, the memory leak is equally severe for me in the latest version (including today's nightly build that contains the fix for bug 866223 with mail.compose.max_recycled_windows=0), so obviously the fix for bug 765074 didn't seem to help much.

While TB has just become usable for me again thanks to fix of 866223 (compose window is cached again) which disguises the memory leak, I still hope that the cause of this leak can be found and fixed.

Comment 49

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #48)
> While TB has just become usable for me again thanks to fix of 866223
> (compose window is cached again) which disguises the memory leak,

I sounds that problem of bug 765074(then produces memory leak of this bug due to non-destroyed objects) occurs only when compose window is actually closed and is not cached and recycled.
i.e. Change in bug 765074 is correct thing.

> I disagree, the memory leak is equally severe for me in the latest version
> (including today's nightly build that contains the fix for bug 866223 with mail.compose.max_recycled_windows=0)

When mail.compose.max_recycled_windows=0, compose window is not recycled. And, if "numper of opened compose windows at same time" is grater than mail.compose.max_recycled_windows value, ("numper of opened compose window at same time" - mail.compose.max_recycled_windows value) windows are actually closed after mail compsition window close.
bug 866223 simply forced mail.compose.max_recycled_windows=0 always regardless of mail.compose.max_recycled_windows setting after Tb 17.

I believe change from "1MB Virtual Memory Size increase per one composition window open/close" to "1MB Virtual Memory Size increase per 20 composition window open/close" indicates that most important and biggest non-destroyed global objects were correctly destroyed after composition window close by patch for bug 765074.

Can you show us transformation of both "Virtual Memory Size" value and "WorkingSet Size" or "Memory Usage"(approximately real memory size MS Win currently reserves for Tb) which is shown by MS Win's Task Manager or "Performance Counter" in your environment?




> > Large memory leak in comment #0 is not observed after fix of bug 765074, and
> > transformation　of virtual memory size is same as comment #17 in trunk
> > nightly(Thunderbird/23.0a1, 20130415030442 build).
> > However, "a few mega bytes VM increase" per "10 to 20 compose window open
> > and close by Send Later" was stil oserved in my quick test.
> 
> I disagree, the memory leak is equally severe for me in the latest version
> (including today's nightly build that contains the fix for bug 866223 with
> mail.compose.max_recycled_windows=0), so obviously the fix for bug 765074
> didn't seem to help much.
> 
 I still
> hope that the cause of this leak can be found and fixed.

Comment 50

[611]

(In reply to WADA from comment #49)
> I sounds that problem of bug 765074(then produces memory leak of this bug
> due to non-destroyed objects) occurs only when compose window is actually
> closed and is not cached and recycled.
> i.e. Change in bug 765074 is correct thing.

Possible, but I simply said that the memory leak wasn't really fixed for me in its severity.

> When mail.compose.max_recycled_windows=0, compose window is not recycled.
> And, if "numper of opened compose windows at same time" is grater than
> mail.compose.max_recycled_windows value, ("numper of opened compose window
> at same time" - mail.compose.max_recycled_windows value) windows are
> actually closed after mail compsition window close.
> bug 866223 simply forced mail.compose.max_recycled_windows=0 always
> regardless of mail.compose.max_recycled_windows setting after Tb 17.

Yes, that's exactly what I said. I tested the latest nightly build with mail.compose.max_recycled_windows=0.
 
> I believe change from "1MB Virtual Memory Size increase per one composition
> window open/close" to "1MB Virtual Memory Size increase per 20 composition
> window open/close" indicates that most important and biggest non-destroyed
> global objects were correctly destroyed after composition window close by
> patch for bug 765074.

Actually it's more like 1MB/open-close for me still. I noticed it's even worse when I open and close the window very fast repeatedly. TB seems to be unable to properly clean up previously used resources due to the fast actions which causes an even bigger leak (generally it somehow seems to take 1-5 seconds to clean up most of the allocated memory). At the same time this type of "overloading" causes repeated large CPU spikes which also slows down TB (it seems like TB tries clean up all this accumulated memory and gets stuck). These spikes get worse the more often the windows is opened/closed. During these short CPU spikes the memory usage often spikes as well and immediately comes back down afterwards (that base amount is still increased by the original leak though, see above). This is a bit hard to explain, but again, this is with the latest nightly build and should be reproducable for everyone.

> Can you show us transformation of both "Virtual Memory Size" value and
> "WorkingSet Size" or "Memory Usage"(approximately real memory size MS Win
> currently reserves for Tb) which is shown by MS Win's Task Manager or
> "Performance Counter" in your environment?

All separate values increase approximately the same for me. I'm afraid I don't have the skill or time to do a video or some other detailed presentation of this.

Comment 51

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #50)
> (generally it somehow seems to take 1-5 seconds to clean up most of the allocated memory).

It's a phenomenon by design. Because destroyed JavaScript object is purged(finally freemained if free heap) by garbage collector, time lag always exists between "widow close" and "final freemain" by garbage collector.
 
> At the same time this type of "overloading" causes repeated large CPU spikes which also slows down TB (snip)

This is one of major reasons why "recycled composition window" was implemented.

Comment 52

[WADA:World Anti-bad-Duping Agency]

FYI.

Following is "Memory Usage" column value and "Vitrual Memory Size" column value shown by Task Manager of MS Win XP-SP3, with mail.compose.max_recycled_windows=0, with following Tb trunk build. 
This is detail of comment #25, and comment #27. 

> Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Thunderbird/23.0a1
> Application Build ID 	20130504031036
> Shown value by Task Manager of MS Windows XP-SP3.  
>                                        Memory Usage    Virtual Memory Size
>   Start Tb                                84,968 K        77,448 K
>   Select All at a local folder(10 mails)  85,000          78,556
>
>   Repeat "pen 8 composition windows(Text mode)"
>      and "close the 8 composition windows".    
>   Note: only 8 windows are opened
>   by Edit Mssae As New for 10 selected mails  
>
>   (1) 1-st 8 wins open/close 
>   (1-a) Edit Messages As New(8 wins)     133,772         136,660
>   (1-b) Close 8 wins, wait for a while   101,192          94,024
>
>   (2) 2-nd 8 wins open/close 
>   (2-a) Edit Messages As New(8 wins)     137,192         140,124
>   (2-b) Close 8 wins, wait for a while   103,844          95,368
>
>   (3) 3-rd 8 wins open/close 
>   (3-a) Edit Messages As New(8 wins)     137,072         140,132
>   (3-b) Close 8 wins, wait for a while   102,972          95,624
>
>   (4) 4-th 8 wins open/close 
>   (4-a) Edit Messages As New(8 wins)     137,296         140,476
>   (4-b) Close 8 wins, wait for a while   104,660          97,428
>
>   (5) 5-t 8 wins open/close 
>   (5-a) Edit Messages As New(8 wins)     137,180         140,376
>   (5-b) Close 8 wins, wait for a while   102,848          95,608
>
>   (6) 6-th 8 wins open/close 
>   (6-a) Edit Messages As New(8 wins)     137,336         140,812
>   (6-b) Close 8 wins, wait for a while   104,408          97,516

Comment 53

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #50)
> but I simply said that the memory leak wasn't really fixed for me in its severity.

As we wrote in comment #25, comment #27, and comment #52, we can't observe *SEVERE" memory leak what was reported to comment #0 of this bug any more in tryserver build and Tb nightly build on which patch for bug 765074 is landed.

To [e-mail]:

Please describe detail of your "memory leak which wasn't really fixed for me in its severity" with data, please, instead of merely saying "severe memory leak still occurs in your environment" without providing data for the "severe memory leak what is still occurring in your environment".

Comment 54

[611]

(In reply to WADA from comment #53)
> Please describe detail of your "memory leak which wasn't really fixed for me
> in its severity" with data, please, instead of merely saying "severe memory
> leak still occurs in your environment" without providing data for the
> "severe memory leak what is still occurring in your environment".

The following data is for repeated open and immediate close of the window at the rate of 1/sec and waiting for at least 10 seconds once every test run is done:

                           Memory Usage           Virtual Memory Size
Initial                      151,184 K                 184,000 K
After 1st 10 open/close      170,072                   203,508
After 2nd 10 open/close      184,116                   217,476
After 3rd 10 open/close      199,644                   233,104

As you can see the memory leak is quite obvious. Again, this was done with the latest nightly build and mail.compose.max_recycled_windows=0.

Let me know if you need more data, but note that the memory continues to increase at the same rate when further test runs are done.

Comment 55

[WADA:World Anti-bad-Duping Agency]

(In reply to 611 from comment #54)
> The following data is for repeated open and immediate close of the window
> at the rate of 1/sec and waiting for at least 10 seconds once every test run is done:

I could observe such "Approximatly 1MB increase of Virtual Memory Size(and Memory Usage too) per one compose window open and close" by; (1) Repeat following operation multiple times(5 to 10 times)
    - Compose window open in HTML mode by "Compose" button,
      and close the compose window *immediately*,
      with mail.compose.max_recycled_windows=0.
    - Wait for a while, but sufficiently long.
(2) Repeat step (1) multiple times
I did do following in my fix verification test.
- Open 5 to 10 compose window in Text mode by Edit Messages As New,
  wait for a while sufficiently to write down Task Manager display,
  and do "Send Later" for the opened window in order to emulate
  ordinal mail composition window close,
  and wait for a while sufficiently to write down Task Manager display,
  in order to wait for garbage collection.
- Repeat above several times.
Memory leak you observed seems my "not so severe memory leak what looks to still remain even after fix of bug 765074" which was observed in my comment #27, because I did "close composition window immediately" sometimes in my tests.

Comment 56

[WADA:World Anti-bad-Duping Agency]

Major difference between (Case-A) main target of bug 765074, and (Case-B) Your case, seems next;
  Case-A : Close composition window by Send, or Send Later.
           (Close window by Tb himself)
  Case-B : Close composition window by Close.
           (via termination request from OS, or via similar one)
           Double click of icon at upper left corner of title bar,
           File/Close, Alt*F4 = "Close" of context menu of MS Window,
           Click of X button at upper right corner of title bar.

As for Case-A, severe memory leak problem was actually resolved, as seen in test results in bug 765074, comment #25 and comment #27 of this bug.

To [e-mail]:
Open separate bug for Case-B what you found, which is memory leak even after fix of bug 765074 and bug 866223, please, with crisp problem description and data like your comment #54.  
I'll keep this bug for only Case-A and close as FIXED again for ease of tracking/analysis/search, after you will open sepatate bug for Case-B, although original "Steps To Reproduce" in comment #0 seems Case-B.

Comment 57

[Petr Vones]

The bug is still there in TB 24.0.1. Editing the message over and over is fixed but after sending few messages the VM goes from initial 100 MB (huh, it used to be < 80 MB several versions before) to 150 MB or more which is even worse than before. Sorry, I don't have exact test case for now but I'm experiencing it every day (running TB session 15 hours daily).

Comment 58

[WADA:World Anti-bad-Duping Agency]

(In reply to Petr Vones from comment #57)
> The bug is still there in TB 24.0.1. Editing the message over and over is
> fixed but after sending few messages the VM goes from initial 100 MB (huh,
> it used to be < 80 MB several versions before) to 150 MB or more which is
> even worse than before.

Sorry but this bug is never for "first increase of VM size by a mail composition after restart" where "initial control block creation for mail composition" is involved.
This bug is for "infinite VM size increase by repeated Send or Send Later", and major part of peoblem is already resolved by bug 765074.
Because bug 866223 was not fixed yet when bug 765074 was fixed, and problem like bug 866223 can be relevant to problem, this bug was re-opened, in order to track status aafter both bug 765074 and bug 866223 are fixed.

Petr Vones, do you see phenomenon like "infinite VM size increase by repeated Send or Send Later"?

Comment 59

[WADA:World Anti-bad-Duping Agency]

Oh, you Petr Vones was bug opener, and initial report by you was "VM increase by repeated open/close of composition window without Sen/Send Later".

Because many comments about "large memory leak problem by bug 765074" were added to your bug, and because your comment #0 was written while bug 765074 and bug 866223 were not fixed yet, as I wrote in comment #56, I think it's better to open new/separate bug for "infinite VM size increase by repeated open/close of composition window without Send/Send Later, even after fix of bug 765074 and bug 866223", in order to avoid confusion, for ease of testing and problem analysis.

Petr Vones, what do you think?

Comment 60

[:aceman]

Petr Vones, have you actually tried the pref mail.compose.max_recycled_windows=0? I am not sure I see any comment from you on this. Does it help you?

Comment 61

[Petr Vones]

(In reply to :aceman from comment #60)
> have you actually tried the pref
> mail.compose.max_recycled_windows=0? I am not sure I see any comment from
> you on this. Does it help you?

Not yet. I will change the prefs value and report back after few days. Still don't know how to reproduce it.

Comment 62

[Petr Vones]

(In reply to :aceman from comment #60)
> have you actually tried the pref mail.compose.max_recycled_windows=0?

No difference. After 14+ hours session and several emails edited (Edit+Save) then Sent the amount of VM Size is over 135 MB daily.

Comment 63

[WADA:World Anti-bad-Duping Agency]

(In reply to Petr Vones from comment #62)
> After 14+ hours session and several emails edited (Edit+Save)
> then Sent the amount of VM Size is over 135 MB daily.

Petr Vones(bug opener), can you provide data like Comment #54?
Please note that "amount of VM Size is over 135 MB daily" only can not be an sure evidence of "severe memory leak".
And, please isolate "VM size increase from initial VM size after several composition window open/close(or Send)" and "VM size increase between a 'many open/close(or Send)' and next 'many open/close(or Send)'".
.
"

Comment 64

[Wayne Mery (:wsmwk)]

> Petr Vones(bug opener), can you provide data like Comment #54?

Sounds like this is now minor. Perhaps even just a duplicate of wne of the blocking bugs?

Comment 65

[Petr Vones]

Yes, it is no longer significant issue with TB 31.6.0. I'll retest on next major version (if ever released).

Comment 66

[Phoenix]

Resolved per whiteboard and Comment 65