880193 - ASan: alloc-dealloc-mismatch (malloc vs operator delete) in gfx/skia vs. gfx/2d

Status: REOPENED

(Core :: Graphics, defect)

Description

[Christian Holler (:decoder)]

There is an alloc-dealloc-mismatch showing up on ASan when running mochitests (trace from mozilla-central revision 8b1bfcf0ce6e, optimized build):


65851 INFO TEST-START | /tests/content/events/test/test_bug659071.html
65852 INFO TEST-INFO | /tests/content/events/test/test_bug659071.html | must wait for load
65853 INFO TEST-PASS | /tests/content/events/test/test_bug659071.html | failed to reset zoom
=================================================================
==3407==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x60800062e220
#0 0x41c7ab in operator delete(void*) _asan_rtl_
#1 0x7f17db340645 in SkRefCnt::unref() const gfx/skia/include/core/SkRefCnt.h:66
#2 0x7f17d6c44b93 in ScaleRunner::Run() image/src/RasterImage.cpp:348
#3 0x7f17da4f3c3c in NS_ProcessNextEvent(nsIThread*, bool) objdir-ff-asan64opt/xpcom/build/nsThreadUtils.cpp:238
#4 0x7f17da5bd21d in nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:265
#5 0x7f17e224385a in _pt_root nsprpub/pr/src/pthreads/ptthread.c:204
#6 0x423e40 in __asan::AsanThread::ThreadStart(unsigned long) _asan_rtl_
0x60800062e220 is located 0 bytes inside of 96-byte region [0x60800062e220,0x60800062e280)
allocated by thread T73 (Image Scaler) here:
#0 0x41c18b in __interceptor_malloc _asan_rtl_
#1 0x7f17e20ed4e8 in moz_xmalloc memory/mozalloc/mozalloc.cpp:54
#2 0x7f17db213b44 in skia::ImageOperations::ResizeBasic(SkBitmap const&, skia::ImageOperations::ResizeMethod, int, int, SkIRect const&, void*) gfx/2d/image_operations.cpp:523
#3 0x7f17db213f01 in skia::ImageOperations::Resize(SkBitmap const&, skia::ImageOperations::ResizeMethod, int, int, SkIRect const&, void*) gfx/2d/image_operations.cpp:370
#4 0x7f17db2532fd in mozilla::gfx::Scale(unsigned char*, int, int, int, unsigned char*, int, int, int, mozilla::gfx::SurfaceFormat) gfx/2d/Scale.cpp:42
#5 0x7f17d6c44b93 in ScaleRunner::Run() image/src/RasterImage.cpp:348
#6 0x7f17da4f3c3c in NS_ProcessNextEvent(nsIThread*, bool) objdir-ff-asan64opt/xpcom/build/nsThreadUtils.cpp:238
#7 0x7f17da5bd21d in nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:265
#8 0x7f17e224385a in _pt_root nsprpub/pr/src/pthreads/ptthread.c:204
#9 0x423e40 in __asan::AsanThread::ThreadStart(unsigned long) _asan_rtl_
Thread T73 (Image Scaler) created by T0 here:
#0 0x4104db in __interceptor_pthread_create _asan_rtl_
#1 0x7f17e223fb0d in _PR_CreateThread nsprpub/pr/src/pthreads/ptthread.c:444
#2 0x7f17e223f667 in PR_CreateThread nsprpub/pr/src/pthreads/ptthread.c:527
==3407==HINT: if you don't care about these warnings you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
==3407==ABORTING
TEST-UNEXPECTED-FAIL | /tests/content/events/test/test_bug659071.html | Exited with code 1 during test run


Basically this means skia is using malloc through moz_xmalloc to allocate memory, but then delete is used on the memory to free it.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

George, do I recall this was mentioned as something we knew about?

Comment 2

[George Wright (:gw280) (needinfo me!)]

bjacob said it can't possibly be an issue... I will needinfo him.

Related bug is bug 872509

Comment 3

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

Indeed, ASan needs to be informed that these different methods are all going through the same underlying memory allocator. If they didn't, we would have all sorts of crashes and corruption. We actually had that in the past (until 1 year ago on Android) and that was quite terrible. It definitely was big on crash-stats, when it was happening. I am not aware of any such problem having resurfaced.

Side note: here is Julian's blog from when he added support to Valgrind to support jemalloc:
https://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/

Comment 4

[Christian Holler (:decoder)]

Please leave this bug open. The issue is not fixed yet and we need to track this for the Clang 3.3rc1 update.

Furthermore, the problem is not related to jemalloc or ASan not being informed about the allocator. We also don't need support for ASan in jemalloc (ASan builds don't even use jemalloc). If you want a precise description what the problem in ASan is, see http://code.google.com/p/address-sanitizer/issues/detail?id=193#c3 .

Comment 5

[Christian Holler (:decoder)]

Sorry, last comment went to the wrong bug. 

However, referring to this bug: We don't use jemalloc for ASan builds. So this issue cannot be related to jemalloc.

Comment 6

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

Sorry, I misunderstood.

With jemalloc, mismatches between malloc and c++ operator delete don't matter as they all go through jemalloc. But without jemalloc, this mismatch does matter as these might be different allocators. And we really want to support non-jemalloc, I think. So yes, this is a big deal. Sorry about the noise.

CC'ing glandium.