815288 - Valgrind reports allocator mismatch in nsBufferedStream::Close()

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

Running on linux 64bit in valgrind, with jemalloc ( https://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/ ), I get this:

==29143== Mismatched free() / delete / delete []
==29143==    at 0x402AD2F: operator delete[](void*) (vg_replace_malloc.c:515)
==29143==    by 0x6DABE05: nsBufferedStream::Close() (nsBufferedStreams.cpp:87)
==29143==    by 0x6DABAD3: nsBufferedStream::~nsBufferedStream() (nsBufferedStreams.cpp:60)
==29143==    by 0x6DAB536: nsBufferedInputStream::~nsBufferedInputStream() (in /hack/mozilla-central/obj-firefox-debug/toolkit/library/libxul.so)
==29143==    by 0x6DAB569: nsBufferedInputStream::~nsBufferedInputStream() (nsBufferedStreams.h:73)
==29143==    by 0x6DABC3D: nsBufferedStream::Release() (in /hack/mozilla-central/obj-firefox-debug/toolkit/library/libxul.so)
==29143==    by 0x6DAC2DB: nsBufferedInputStream::Release() (nsBufferedStreams.cpp:249)
==29143==    by 0x6D51D5E: nsCOMPtr_base::~nsCOMPtr_base() (nsCOMPtr.h:494)
==29143==    by 0x75DAF2F: nsSyncLoadService::PushSyncStreamToListener(nsIInputStream*, nsIStreamListener*, nsIChannel*) (nsSyncLoadService.cpp:386)
==29143==    by 0x732CD91: mozilla::css::Loader::LoadSheet(mozilla::css::SheetLoadData*, mozilla::css::StyleSheetState) (Loader.cpp:1426)
==29143==    by 0x7330686: mozilla::css::Loader::LoadChildSheet(nsCSSStyleSheet*, nsIURI*, nsMediaList*, mozilla::css::ImportRule*) (Loader.cpp:2075)
==29143==    by 0x73413D9: (anonymous namespace)::CSSParserImpl::ProcessImport(nsString const&, nsMediaList*, void (*)(mozilla::css::Rule*, void*), void*) (nsCSSParser.cpp:1933)
==29143==  Address 0x5d62710 is 0 bytes inside a block of size 15,478 alloc'd
==29143==    at 0x402C5DE: malloc (vg_replace_malloc.c:271)
==29143==    by 0x4044099: moz_malloc (mozalloc.cpp:64)
==29143==    by 0x6DAB3C8: operator new[](unsigned long, mozilla::fallible_t const&) (mozalloc.h:274)
==29143==    by 0x6DABD73: nsBufferedStream::Init(nsISupports*, unsigned int) (nsBufferedStreams.cpp:76)
==29143==    by 0x6DAC67A: nsBufferedInputStream::Init(nsIInputStream*, unsigned int) (nsBufferedStreams.cpp:285)
==29143==    by 0x6EC4B3A: NS_NewBufferedInputStream(nsIInputStream**, nsIInputStream*, unsigned int) (nsNetUtil.h:1048)
==29143==    by 0x75DACB4: nsSyncLoadService::PushSyncStreamToListener(nsIInputStream*, nsIStreamListener*, nsIChannel*) (nsSyncLoadService.cpp:348)
==29143==    by 0x732CD91: mozilla::css::Loader::LoadSheet(mozilla::css::SheetLoadData*, mozilla::css::StyleSheetState) (Loader.cpp:1426)
==29143==    by 0x7330686: mozilla::css::Loader::LoadChildSheet(nsCSSStyleSheet*, nsIURI*, nsMediaList*, mozilla::css::ImportRule*) (Loader.cpp:2075)
==29143==    by 0x73413D9: (anonymous namespace)::CSSParserImpl::ProcessImport(nsString const&, nsMediaList*, void (*)(mozilla::css::Rule*, void*), void*) (nsCSSParser.cpp:1933)
==29143==    by 0x7341217: (anonymous namespace)::CSSParserImpl::ParseImportRule(void (*)(mozilla::css::Rule*, void*), void*) (nsCSSParser.cpp:1904)
==29143==    by 0x733FE29: (anonymous namespace)::CSSParserImpl::ParseAtRule(void (*)(mozilla::css::Rule*, void*), void*, bool) (nsCSSParser.cpp:1531)
==29143== 


Is Valgrind just being confused here by the operator new[](unsigned long, mozilla::fallible_t const&) ? Or is this real?

Using Valgrind SVN r13059

Comment 1

[Julian Seward [:jseward]]

> Is Valgrind just being confused here by the operator new[](unsigned long,
> mozilla::fallible_t const&) ?

Yes.

> Or is this real?

No.

Problem has occurred because V expects the nothrow [] operator to be called
'operator new(unsigned long, std::nothrow_t const&)' (_ZnwmRKSt9nothrow_t
when mangled).  See coregrind/m_replacemalloc/vg_replacemalloc.c:327.

It therefore fails to intercept the allocation call, which calls
onwards in the normal way to moz_malloc and then plain malloc, which
it does intercept.

Hence it winds up believing (wrongly) that the block is allocated by
malloc but freed by delete [].

Not sure what the right fix is here.  Is there a 'operator
new(unsigned long, std::nothrow_t const&)' that got inlined somehow?
Adding an intercept for 'new[](unsigned long, mozilla::fallible_t
const&)' would fix it, but I am reluctant to add intercepts for
mozilla-specific allocators in the stock V sources.