227175 - Collation should be freed [@nsMsgDBFolder]

Status: RESOLVED FIXED

(Core :: Internationalization: Localization, defect)

Description

[Daniel de Wildt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.6b) Gecko/20031125
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.6b) Gecko/20031125

Maybe I'm wrong, but I think that the collation (kCollationKeyGenerator) created
in nsMsgDBFolder::createCollationKeyGenerator is not freed.
More details in the attachments (tree.log)

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla
2. Stop Mozilla
Actual Results:  
Memory leak

Comment 1

[Daniel de Wildt]

Attachment: Tree with unbalanced reference

I think the source of the leak is in (or below)
nsMsgDBFolder::createCollationKeyGenerator

Comment 2

[Daniel de Wildt]

Attachment: bloat.log with leaking instances

The leaking classes nsCollation, nsCollationWin and nsBasicEncoder depends on
this leak.

Comment 3

[[e-mail]]

My bad - I converted a bunch of atoms to a static atom table and inadvertantly
deleted the release of kCollationKeyGenerator at the same time.

Comment 4

[[e-mail]]

Attachment: Fix regression

Comment 5

[David :Bienvenu]

Comment on attachment 136582 [details] [diff] [review]
Fix regression

this variable should be called gCollationKeyGenerator, not k - it's global, not
const - that might be why you forgot to free it :-) feel free to fix that as
well.

Comment 6

[[e-mail]]

Comment on attachment 136582 [details] [diff] [review]
Fix regression

Low-risk memory leak regression fix (I'll fix the variable name issue in 1.7a).

Comment 7

[[e-mail]]

Fix checked in.

Comment 8

[[e-mail]]

Attachment: variable name change as requested

Comment 9

[David :Bienvenu]

Comment on attachment 136638 [details] [diff] [review]
variable name change as requested

thx

Comment 10

[[e-mail]]

Reopening to track variable name issue.

Comment 11

[[e-mail]]

Fix checked in.