495038 - Valgrind's list of memory leaks on thunderbird exit

Status: NEW

(Thunderbird :: General, defect)

Description

[Zdenek Kabelac]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4
Build Identifier: thunderbird-3.0-2.5.b3pre.hg.6a6386c16e98.fc11.x86_64

I'm providing list of memory leaks shown by valgrind - certainly a lot of them are 'false positives' as they are most probably only static variables allocated just once - but in the list seems to be way to many allocations that have large amount of instances - here is short the list of suspects:

morkArray
CSSLoaderImpl
CSSParserImpl
nsXBLService




Reproducible: Always

Steps to Reproduce:
1. start TB
2. open and read few mails from Inbox
3. open and read few news group messages

Comment 1

[Zdenek Kabelac]

Attachment: valgrind's list of memory leaks

Comment 2

[Mark Banner (:standard8)]

Thanks for the list.

Having just done a very quick initial scan I think a lot of the leaks are the same issue as bug 426963. These are the ones where we createInstance or getService and we're leaking some of those, these can also be tracked by our own reference counting as seen in bug 426963. Therefore adding dependency.

Of the remained I especially noticed:

==12380== 8 bytes in 1 blocks are still reachable in loss record 4 of 327
==12380==    at 0x4C24FFC: operator new(unsigned long) (vg_replace_malloc.c:230)
==12380==    by 0x25D104A3: MakeMdbFactory (morkFactory.cpp:150)
==12380==    by 0x25D0A8BD: nsMorkFactoryService::GetMdbFactory(nsIMdbFactory**) (nsMorkFactory.cpp:78)
==12380==    by 0x184EB08C: nsMsgFolderCache::GetMDBFactory(nsIMdbFactory**) (nsMsgFolderCache.cpp:82)
==12380==    by 0x184EB107: nsMsgFolderCache::OpenMDB(nsACString_internal const&, int) (nsMsgFolderCache.cpp:165)
==12380==    by 0x184EB45E: nsMsgFolderCache::Init(nsIFile*) (nsMsgFolderCache.cpp:275)

This looks like we're allocating an orkinHeap object and not freeing it.

==12380== 709,407 bytes in 649 blocks are still reachable in loss record 327 of 327
==12380==    at 0x4C24FFC: operator new(unsigned long) (vg_replace_malloc.c:230)
==12380==    by 0x25D0AA48: orkinHeap::Alloc(nsIMdbEnv*, unsigned int, void**) (orkinHeap.cpp:90)
==12380==    by 0x25D0AE80: morkArray::morkArray(morkEnv*, morkUsage const&, nsIMdbHeap*, unsigned int, nsIMdbHeap*) (morkArray.cpp:104)
==12380==    by 0x25D214F6: morkTable::morkTable(morkEnv*, morkUsage const&, nsIMdbHeap*, morkStore*, nsIMdbHeap*, morkRowSpace*, mdbOid const*, unsigned int, unsigned int, unsigned char) (morkTable.cpp:138)
==12380==    by 0x25D1BB26: morkRowSpace::NewTableWithTid(morkEnv*, unsigned int, unsigned int, mdbOid const*) (morkRowSpace.cpp:327)
==12380==    by 0x25D1DA33: morkStore::MidToTable(morkEnv*, morkMid const&) (morkStore.cpp:798)

Also looks concerning, especially with the large allocation.

I'll take a bit more of a look later and possibly file some bugs.

Comment 3

[David :Bienvenu]

If we're not closing a db, all those mork allocations would show up as leaks.

Comment 4

[Wayne Mery (:wsmwk)]

(this wouldn't be OS specific)