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.

They're nsAutoPtrs, no?

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.

What other objects were leaked in this leak report?

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

(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.