643300 - ParseDeclarationBlock leaks the compressed data for the declaration created in nsCSSExpandedDataBlock::Compress

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[(no longer active)]

The OS X leaks tool reports this memory leak:

Leak: 0x1042b2c00  size=1536  zone: DefaultMallocZone_0x103319000       
        0x00038080 0x00000080 0x042b3060 0x00000001     ........`0+.....
        0x00000000 0x00000001 0x00000047 0x00000001     ........G.......
        0x00000000 0x00000000 0x00000012 0x00000001     ................
        0x00000047 0x00000001 0x00000001 0x00000001     G...............
        0x00000013 0x00000001 0x00000004 0x00000000     ................
        0x00000000 0x00000000 0x00000014 0x00000001     ................
        0x00000047 0x00000000 0x00000000 0x00000000     G...............
        0x00000015 0x00000001 0x00000389 0x00000001     ................
        ...
        Call stack: [thread 0x7fff7110eca0]: | start | main | XRE_main | nsAppStartup::Run() | nsAppShell::Run() | -[NSApplication run] | -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] | _DPSNextEvent | BlockUntilNextEventMatchingListInMode | ReceiveNextEventCommon | RunCurrentEventLoopInMode | CFRunLoopRunSpecific | __CFRunLoopRun | __CFRunLoopDoSources0 | nsAppShell::ProcessGeckoEvents(void*) | nsBaseAppShell::NativeEventCallback() | NS_ProcessPendingEvents_P(nsIThread*, unsigned int) | nsThread::ProcessNextEvent(int, int*) | nsInputStreamReadyEvent::Run() | nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) | nsInputStreamPump::OnStateTransfer() | nsBaseChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) | nsParser::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) | nsParser::ResumeParse(int, int, int) | nsParser::Tokenize(int) | nsExpatDriver::ConsumeToken(nsScanner&, int&) | nsExpatDriver::ParseBuffer(unsigned short const*, unsigned int, int, unsigned int*) | MOZ_XML_Parse | prologInitProcessor | doProlog | doContent | nsExpatDriver::HandleStartElement(unsigned short const*, unsigned short const**) | XULContentSinkImpl::HandleStartElement(unsigned short const*, unsigned short const**, unsigned int, int, unsigned int) | XULContentSinkImpl::OpenTag(unsigned short const**, unsigned int, unsigned int, nsINodeInfo*) | XULContentSinkImpl::AddAttributes(unsigned short const**, unsigned int, nsXULPrototypeElement*) | nsXULPrototypeElement::SetAttrAt(unsigned int, nsAString_internal const&, nsIURI*) | nsCSSParser::ParseStyleAttribute(nsAString_internal const&, nsIURI*, nsIURI*, nsIPrincipal*, nsICSSStyleRule**) | (anonymous namespace)::CSSParserImpl::ParseDeclarationBlock(int) | nsCSSExpandedDataBlock::Compress(nsCSSCompressedDataBlock**, nsCSSCompressedDataBlock**) | moz_xmalloc | malloc | malloc_zone_malloc 

css::Declaration's destructor doesn't delete mData and mImportantData, and it seems to me that we're just leaking these two objects when a Declaration object created in ParseDeclarationBlock goes out of scope.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

They're nsAutoPtrs, no?

Comment 2

[(no longer active)]

Hmm, mData and mImportantData are nsAutoPtr's, so what I said in comment 0 shouldn not be the case...  I don't know what's going on here.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What other objects were leaked in this leak report?

Comment 4

[(no longer active)]

Hmm, do we store any pointers in the style system in a masked form, such as by anding them by 0x1, for example?

Comment 5

[(no longer active)]

(In reply to comment #4)
> Hmm, do we store any pointers in the style system in a masked form, such as by
> anding them by 0x1, for example?

That's how nsAttrValue stores its value.  So this bug is INVALID.