Oilpan: Defer reusing freed memory for one GC cycle

Oilpan: Defer reusing freed memory for one GC cycle

This CL defers reusing freed memory for (at least) one GC cycle or coalescing. This is helpful to detect use-after-free errors caused by lazy sweeping (it is scary!).

Before this CL, the deferment is enabled only on ASan builds. This CL enables the deferment in non-production builds (i.e., ASSERT || LSan || ASan).

See the comment in addToFreeList() for how the deferment is implemented.

BUG=420515
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=196997

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=197289

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=198184

[haraken, 2015-06-10 13:25:52]

haraken@chromium.org changed reviewers:
+ oilpan-reviews@chromium.org, sigbjornf@opera.com

[haraken, 2015-06-10 13:26:26]

PTAL

[sof, 2015-06-10 13:57:39]

lgtm

[haraken, 2015-06-10 15:21:17]

I noticed a fundamental problem of this CL...

If we delay reusing freed memory, it means that we always fail at allocating
objects in lazy sweeping. This means that completeSweep() runs when allocating
the first object after the last GC. Lazy sweeping doesn't run.

We already delay reusing freed memory on ASan builds. Does this imply that lazy
sweeping is not working on ASan bulids already???

[haraken, 2015-06-12 01:14:36]

On 2015/06/10 15:21:17, haraken wrote:
> I noticed a fundamental problem of this CL...
> 
> If we delay reusing freed memory, it means that we always fail at allocating
> objects in lazy sweeping. This means that completeSweep() runs when allocating
> the first object after the last GC. Lazy sweeping doesn't run.
> 
> We already delay reusing freed memory on ASan builds. Does this imply that
lazy
> sweeping is not working on ASan bulids already???

^^^ Ignore this comment. Given that there are free lists that have been freed in
the past GCs, lazySweeping() can succeed in allocating objects by reusing the
free lists.

Added a test to verify that a freelist is not reused in the first GC but is
reused in the second or later GC.

[haraken, 2015-06-12 01:14:40]

The CQ bit was checked by haraken@chromium.org

[haraken, 2015-06-12 01:14:41]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1176003002/#ps40001
(title: " ")

[commit-bot: I haz the power, 2015-06-12 01:15:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1176003002/40001

[commit-bot: I haz the power, 2015-06-12 04:35:14]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=196997

[haraken, 2015-06-17 21:11:43]

I think the latest CL fixes the ASan breakage. (It's unfortunate that we don't
have an ASan trybot... it's hard to run ASan for al tests through my limited SSH
-X environment.)

https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
File Source/platform/heap/Heap.cpp (right):

https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
Source/platform/heap/Heap.cpp:1056: ASAN_POISON_MEMORY_REGION(address, size);

If we delay this ASAN_POISON_MEMORY_REGION, we need to duplicate the
ASAN_POISON_MEMORY_REGION at every return. So I decided to leave this as is and
use NO_SANITIZE_ADDRESS.

[haraken, 2015-06-17 21:11:48]

The CQ bit was checked by haraken@chromium.org

[haraken, 2015-06-17 21:11:49]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1176003002/#ps80001
(title: " ")

[commit-bot: I haz the power, 2015-06-17 21:12:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1176003002/80001

[commit-bot: I haz the power, 2015-06-17 22:20:05]

Committed patchset #5 (id:80001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=197289

[sof, 2015-06-18 05:15:36]

On 2015/06/17 21:11:43, haraken wrote:
> I think the latest CL fixes the ASan breakage. (It's unfortunate that we don't
> have an ASan trybot... it's hard to run ASan for al tests through my limited
SSH
> -X environment.)
> 
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> File Source/platform/heap/Heap.cpp (right):
> 
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> Source/platform/heap/Heap.cpp:1056: ASAN_POISON_MEMORY_REGION(address, size);
> 
> If we delay this ASAN_POISON_MEMORY_REGION, we need to duplicate the
> ASAN_POISON_MEMORY_REGION at every return. So I decided to leave this as is
and
> use NO_SANITIZE_ADDRESS.

It is causing meltdown?
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Oilpan%...

[haraken, 2015-06-18 05:17:41]

On 2015/06/18 05:15:36, sof wrote:
> On 2015/06/17 21:11:43, haraken wrote:
> > I think the latest CL fixes the ASan breakage. (It's unfortunate that we
don't
> > have an ASan trybot... it's hard to run ASan for al tests through my limited
> SSH
> > -X environment.)
> > 
> >
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> > File Source/platform/heap/Heap.cpp (right):
> > 
> >
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> > Source/platform/heap/Heap.cpp:1056: ASAN_POISON_MEMORY_REGION(address,
size);
> > 
> > If we delay this ASAN_POISON_MEMORY_REGION, we need to duplicate the
> > ASAN_POISON_MEMORY_REGION at every return. So I decided to leave this as is
> and
> > use NO_SANITIZE_ADDRESS.
> 
> It is causing meltdown?
>
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Oilpan%...

Already reverted :)

It seems I should reland this after I get a non-SSH environment where I can run
all tests with ASan locally.

[haraken, 2015-06-22 09:40:26]

Now the ASan symbols are broken and it's hard to investigate the issue without
getting https://code.google.com/p/chromium/issues/detail?id=502974 fixed.

[haraken, 2015-06-22 11:27:39]

haraken@chromium.org changed reviewers:
+ glider@chromium.org

[haraken, 2015-06-22 11:27:39]

+glider

https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
File Source/platform/heap/Heap.cpp (right):

https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
Source/platform/heap/Heap.cpp:1101: address[i] = reuseForbiddenZapValue;

It seems that this line is causing use-after-poison. I'm wondering why this is
detected as use-after-poison whereas I marked addToFreeList as
NO_SANITIZE_ADDRESS.

https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Linux_ASA...

[haraken, 2015-06-22 11:29:52]

On 2015/06/22 11:27:39, haraken wrote:
> +glider
> 
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> File Source/platform/heap/Heap.cpp (right):
> 
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> Source/platform/heap/Heap.cpp:1101: address[i] = reuseForbiddenZapValue;
> 
> It seems that this line is causing use-after-poison. I'm wondering why this is
> detected as use-after-poison whereas I marked addToFreeList as
> NO_SANITIZE_ADDRESS.
> 
>
https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Linux_ASA...

Also a strange thing is that the use-after-poison happens only on Release
builds. It doesn't happen on Debug builds.

[haraken, 2015-06-22 11:33:11]

On 2015/06/22 11:29:52, haraken wrote:
> On 2015/06/22 11:27:39, haraken wrote:
> > +glider
> > 
> >
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> > File Source/platform/heap/Heap.cpp (right):
> > 
> >
>
https://codereview.chromium.org/1176003002/diff/80001/Source/platform/heap/He...
> > Source/platform/heap/Heap.cpp:1101: address[i] = reuseForbiddenZapValue;
> > 
> > It seems that this line is causing use-after-poison. I'm wondering why this
is
> > detected as use-after-poison whereas I marked addToFreeList as
> > NO_SANITIZE_ADDRESS.
> > 
> >
>
https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Linux_ASA...
> 
> Also a strange thing is that the use-after-poison happens only on Release
> builds. It doesn't happen on Debug builds.

I identified the cause. It would be because addToFreeList is sometimes inlined
on Release builds :) Sorry about the noise!

[Alexander Potapenko, 2015-06-25 14:45:17]

> I identified the cause. It would be because addToFreeList is sometimes inlined
> on Release builds :) Sorry about the noise!

How did you figure this out?
I've been told that __attribute((no_sanitize_address)) on a function prevents
its inlining.

[sof, 2015-06-25 14:54:11]

On 2015/06/25 14:45:17, Alexander Potapenko wrote:
> > I identified the cause. It would be because addToFreeList is sometimes
inlined
> > on Release builds :) Sorry about the noise!
> 
> How did you figure this out?
> I've been told that __attribute((no_sanitize_address)) on a function prevents
> its inlining.

It's in the other direction in this case, being inlined into a function with an
annotation. addToFreeList() inlined into NormalPageHeap::allocatePage() (which
is annotated.)

Is that prevented also? (it makes good sense, i think.)

[Alexander Potapenko, 2015-06-25 15:05:52]

On 2015/06/25 14:54:11, sof wrote:
> On 2015/06/25 14:45:17, Alexander Potapenko wrote:
> > > I identified the cause. It would be because addToFreeList is sometimes
> inlined
> > > on Release builds :) Sorry about the noise!
> > 
> > How did you figure this out?
> > I've been told that __attribute((no_sanitize_address)) on a function
prevents
> > its inlining.
> 
> It's in the other direction in this case, being inlined into a function with
an
> annotation. addToFreeList() inlined into NormalPageHeap::allocatePage() (which
> is annotated.)
Sorry, I don't get it.
As long as addToFreeList() is inlined into a function with
__attribute((no_sanitize_address)), ASan doesn't instrument addToFreeList().
In that case the tool cannot report errors in addToFreeList().
> Is that prevented also? (it makes good sense, i think.)
No idea, but I agree it makes sense.

[sof, 2015-06-25 15:11:06]

On 2015/06/25 15:05:52, Alexander Potapenko wrote:
> On 2015/06/25 14:54:11, sof wrote:
> > On 2015/06/25 14:45:17, Alexander Potapenko wrote:
> > > > I identified the cause. It would be because addToFreeList is sometimes
> > inlined
> > > > on Release builds :) Sorry about the noise!
> > > 
> > > How did you figure this out?
> > > I've been told that __attribute((no_sanitize_address)) on a function
> prevents
> > > its inlining.
> > 
> > It's in the other direction in this case, being inlined into a function with
> an
> > annotation. addToFreeList() inlined into NormalPageHeap::allocatePage()
(which
> > is annotated.)
> Sorry, I don't get it.
> As long as addToFreeList() is inlined into a function with
> __attribute((no_sanitize_address)), ASan doesn't instrument addToFreeList().
> In that case the tool cannot report errors in addToFreeList().
> > Is that prevented also? (it makes good sense, i think.)
> No idea, but I agree it makes sense.

But, hmm, wouldn't such inlining increase the scope of a no-sanitize annotation?
Which is the opposite of what's reported as being a problem.

@haraken: could you explain? :-)

[haraken, 2015-06-26 00:20:22]

On 2015/06/25 15:11:06, sof wrote:
> On 2015/06/25 15:05:52, Alexander Potapenko wrote:
> > On 2015/06/25 14:54:11, sof wrote:
> > > On 2015/06/25 14:45:17, Alexander Potapenko wrote:
> > > > > I identified the cause. It would be because addToFreeList is sometimes
> > > inlined
> > > > > on Release builds :) Sorry about the noise!
> > > > 
> > > > How did you figure this out?

This is just a guess from the fact that the ASan error happens only on Release
builds.

> > > > I've been told that __attribute((no_sanitize_address)) on a function
> > prevents
> > > > its inlining.
> > > 
> > > It's in the other direction in this case, being inlined into a function
with
> > an
> > > annotation. addToFreeList() inlined into NormalPageHeap::allocatePage()
> (which
> > > is annotated.)
> > Sorry, I don't get it.
> > As long as addToFreeList() is inlined into a function with
> > __attribute((no_sanitize_address)), ASan doesn't instrument addToFreeList().
> > In that case the tool cannot report errors in addToFreeList().

That would be because addToFreeList() is called from other functions (which
don't have NO_SANITIZE_ADDRESS). I guess those functions inline the
addToFreeList and report the ASan error.

The patch set 6 fixes most of the ASan errors, but I'm still hitting some.
However, I don't figure out where it's hitting the error because the ASan's
stack is broken...

[sof, 2015-06-26 06:50:06]

On 2015/06/26 00:20:22, haraken wrote:
> On 2015/06/25 15:11:06, sof wrote:
> > On 2015/06/25 15:05:52, Alexander Potapenko wrote:
> > > On 2015/06/25 14:54:11, sof wrote:
> > > > On 2015/06/25 14:45:17, Alexander Potapenko wrote:
> > > > > > I identified the cause. It would be because addToFreeList is
sometimes
> > > > inlined
> > > > > > on Release builds :) Sorry about the noise!
> > > > > 
> > > > > How did you figure this out?
> 
> This is just a guess from the fact that the ASan error happens only on Release
> builds.
> 
> > > > > I've been told that __attribute((no_sanitize_address)) on a function
> > > prevents
> > > > > its inlining.
> > > > 
> > > > It's in the other direction in this case, being inlined into a function
> with
> > > an
> > > > annotation. addToFreeList() inlined into NormalPageHeap::allocatePage()
> > (which
> > > > is annotated.)
> > > Sorry, I don't get it.
> > > As long as addToFreeList() is inlined into a function with
> > > __attribute((no_sanitize_address)), ASan doesn't instrument
addToFreeList().
> > > In that case the tool cannot report errors in addToFreeList().
> 
> That would be because addToFreeList() is called from other functions (which
> don't have NO_SANITIZE_ADDRESS). I guess those functions inline the
> addToFreeList and report the ASan error.
> 
> The patch set 6 fixes most of the ASan errors, but I'm still hitting some.
> However, I don't figure out where it's hitting the error because the ASan's
> stack is broken...

Ah, thanks. ps#5 had that annotation on addToFreeList().

So, yes, not inlining annotated functions might be less confusing.

[Alexander Potapenko, 2015-06-26 09:09:06]

> That would be because addToFreeList() is called from other functions (which
> don't have NO_SANITIZE_ADDRESS). I guess those functions inline the
> addToFreeList and report the ASan error.
According to my understanding of __attribute__((no_sanitize_address))
addToFreeList() can't be inlined into other functions exactly because it's
annotated. 
> The patch set 6 fixes most of the ASan errors, but I'm still hitting some.
> However, I don't figure out where it's hitting the error because the ASan's
> stack is broken...

[haraken, 2015-07-02 03:43:44]

The patch set 7 passes all http/tests/ with ASan. Let me try to land it.

[haraken, 2015-07-02 03:43:59]

The CQ bit was checked by haraken@chromium.org

[haraken, 2015-07-02 03:43:59]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1176003002/#ps120001
(title: " ")

[commit-bot: I haz the power, 2015-07-02 03:44:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1176003002/120001

[commit-bot: I haz the power, 2015-07-02 05:11:19]

Committed patchset #7 (id:120001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=198184

[sof, 2015-07-02 07:01:47]

ASan bots are failing 


http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20ASAN/bu...

same for Oilpan.

[haraken, 2015-07-02 07:03:02]

On 2015/07/02 07:01:47, sof wrote:
> ASan bots are failing 
> 
> 
>
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20ASAN/bu...
> 
> same for Oilpan.

looking... http/tests/ were passing locally...

[sof, 2015-07-02 07:10:17]

On 2015/07/02 07:03:02, haraken wrote:
> On 2015/07/02 07:01:47, sof wrote:
> > ASan bots are failing 
> > 
> > 
> >
>
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20ASAN/bu...
> > 
> > same for Oilpan.
> 
> looking... http/tests/ were passing locally...

I can't reproduce in Debug locally, but the bots are Release.

[haraken, 2015-07-02 07:12:11]

On 2015/07/02 07:10:17, sof wrote:
> On 2015/07/02 07:03:02, haraken wrote:
> > On 2015/07/02 07:01:47, sof wrote:
> > > ASan bots are failing 
> > > 
> > > 
> > >
> >
>
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20ASAN/bu...
> > > 
> > > same for Oilpan.
> > 
> > looking... http/tests/ were passing locally...
> 
> I can't reproduce in Debug locally, but the bots are Release.

thanks, that is plausible. Trying to reproduce locally.

[haraken, 2015-07-02 07:31:55]

This is the crash trace. It seems that allocatePage is inlined, even though
allocatePage has NO_SANITIZE_ADDRESS.


STDERR: =================================================================
STDERR: ==9380==ERROR: AddressSanitizer: use-after-poison on address
0x3c60b9781828 at pc 0x0000004b075d bp 0x7ffc9518aeb0 sp 0x7ffc9518a670
STDERR: WRITE of size 120792 at 0x3c60b9781828 thread T0 (content_shell)
STDERR:     #0 0x4b075c in __interceptor_memset ??:0:0
STDERR:     #1 0x21d2684 in blink::NormalPageHeap::allocatePage()
third_party/WebKit/Source/platform/heap/Heap.cpp:652:20
STDERR:     #2 0x21d5591 in blink::NormalPageHeap::outOfLineAllocate(unsigned
long, unsigned long) third_party/WebKit/Source/platform/heap/Heap.cpp:925:5
STDERR:     #3 0x505f619 in allocateOnHeapIndex
third_party/WebKit/Source/platform/heap/Heap.h:1345:12
STDERR:     #4 0x505f619 in
allocateHashTableBacking<blink::Member<blink::Resource>,
WTF::HashTable<blink::Member<blink::Resource>, blink::Member<blink::Resource>,
WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
WTF::HashTraits<blink::Member<blink::Resource> >,
WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
third_party/WebKit/Source/platform/heap/HeapAllocator.h:89:0
STDERR:     #5 0x505f619 in
allocateZeroedHashTableBacking<blink::Member<blink::Resource>,
WTF::HashTable<blink::Member<blink::Resource>, blink::Member<blink::Resource>,
WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
WTF::HashTraits<blink::Member<blink::Resource> >,
WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
third_party/WebKit/Source/platform/heap/HeapAllocator.h:94:0
STDERR:     #6 0x505f619 in allocateTable
third_party/WebKit/Source/wtf/HashTable.h:984:0
STDERR:     #7 0x505f619 in WTF::HashTable<blink::Member<blink::Resource>,
blink::Member<blink::Resource>, WTF::IdentityExtractor,
WTF::PtrHash<blink::Member<blink::Resource> >,
WTF::HashTraits<blink::Member<blink::Resource> >,
WTF::HashTraits<blink::Member<blink::Resource> >,
blink::HeapAllocator>::rehash(unsigned int, blink::Member<blink::Resource>*)
third_party/WebKit/Source/wtf/HashTable.h:1141:0
STDERR:     #8 0x505df92 in shrink
third_party/WebKit/Source/wtf/HashTable.h:506:25
STDERR:     #9 0x505df92 in remove
third_party/WebKit/Source/wtf/HashTable.h:945:0
STDERR:     #10 0x505df92 in remove
third_party/WebKit/Source/wtf/HashTable.h:963:0
STDERR:     #11 0x505df92 in remove
third_party/WebKit/Source/wtf/HashSet.h:208:0
STDERR:     #12 0x505df92 in remove
third_party/WebKit/Source/wtf/HashSet.h:214:0
STDERR:     #13 0x505df92 in
blink::MemoryCache::unregisterLiveResource(blink::Resource&)
third_party/WebKit/Source/core/fetch/MemoryCache.cpp:802:0
STDERR:     #14 0x507a3d2 in blink::Resource::deleteIfPossible()
third_party/WebKit/Source/core/fetch/Resource.cpp:646:9
STDERR:     #15 0x507e185 in
blink::Resource::unregisterHandle(blink::ResourcePtrBase*)
third_party/WebKit/Source/core/fetch/Resource.cpp:862:13
STDERR:     #16 0x50870e8 in ~ResourcePtrBase
third_party/WebKit/Source/core/fetch/ResourcePtr.h:69:9
STDERR:     #17 0x50870e8 in ~KeyValuePair
third_party/WebKit/Source/wtf/HashTraits.h:244:0
STDERR:     #18 0x50870e8 in deleteAllBucketsAndDeallocate
third_party/WebKit/Source/wtf/HashTable.h:1012:0
STDERR:     #19 0x50870e8 in finalize
third_party/WebKit/Source/wtf/HashTable.h:413:0
STDERR:     #20 0x50870e8 in ~ConditionalDestructor
third_party/WebKit/Source/wtf/ConditionalDestructor.h:20:0
STDERR:     #21 0x50870e8 in ~HashMap
third_party/WebKit/Source/wtf/HashMap.h:52:0
STDERR:     #22 0x50870e8 in blink::ResourceFetcher::~ResourceFetcher()
third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:178:0
STDERR:     #23 0x21ce3eb in blink::HeapObjectHeader::finalize(unsigned char*,
unsigned long) third_party/WebKit/Source/platform/heap/Heap.cpp:213:9
STDERR:     #24 0x21d7c44 in blink::NormalPage::sweep()
third_party/WebKit/Source/platform/heap/Heap.cpp:1322:13
STDERR:     #25 0x21d05a2 in blink::BaseHeap::sweepUnsweptPage()
third_party/WebKit/Source/platform/heap/Heap.cpp:473:9
STDERR:     #26 0x21d0b2d in blink::BaseHeap::completeSweep()
third_party/WebKit/Source/platform/heap/Heap.cpp:514:9
STDERR:     #27 0x2160d81 in blink::ThreadState::completeSweep()
third_party/WebKit/Source/platform/heap/ThreadState.cpp:1085:13
STDERR:     #28 0x21df37a in ~SafePointScope
third_party/WebKit/Source/platform/heap/SafePoint.h:28:13
STDERR:     #29 0x21df37a in blink::GCScope::~GCScope()
third_party/WebKit/Source/platform/heap/Heap.cpp:185:0
STDERR:     #30 0x21dd0fe in
blink::Heap::collectGarbage(blink::ThreadState::StackState,
blink::ThreadState::GCType, blink::Heap::GCReason)
third_party/WebKit/Source/platform/heap/Heap.cpp:2221:1
STDERR:     #31 0x21df740 in blink::Heap::collectAllGarbage()
third_party/WebKit/Source/platform/heap/Heap.cpp:2321:9
STDERR:     #32 0x216c929 in
blink::ThreadState::safePoint(blink::ThreadState::StackState)
third_party/WebKit/Source/platform/heap/ThreadState.cpp:1164:5
STDERR:     #33 0x60ed94 in base::MessageLoop::RunTask(base::PendingTask const&)
base/message_loop/message_loop.cc:458:3
STDERR:     #34 0x60fac4 in DeferOrRunPendingTask
base/message_loop/message_loop.cc:466:5
STDERR:     #35 0x60fac4 in base::MessageLoop::DoWork()
base/message_loop/message_loop.cc:578:0
STDERR:     #36 0x617ce3 in
base::MessagePumpDefault::Run(base::MessagePump::Delegate*)
base/message_loop/message_pump_default.cc:34:21
STDERR:     #37 0x60db6f in base::MessageLoop::RunHandler()
base/message_loop/message_loop.cc:422:3
STDERR:     #38 0x63941b in base::RunLoop::Run() base/run_loop.cc:55:3
STDERR:     #39 0x60bb28 in base::MessageLoop::Run()
base/message_loop/message_loop.cc:286:3
STDERR:     #40 0x80c689d in content::RendererMain(content::MainFunctionParams
const&) content/renderer/renderer_main.cc:220:7
STDERR:     #41 0x5a1601 in content::RunZygote(content::MainFunctionParams
const&, content::ContentMainDelegate*) content/app/content_main_runner.cc:308:14
STDERR:     #42 0x5a233f in
content::RunNamedProcessTypeMain(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
content::MainFunctionParams const&, content::ContentMainDelegate*)
content/app/content_main_runner.cc:392:12
STDERR:     #43 0x5a3922 in content::ContentMainRunnerImpl::Run()
content/app/content_main_runner.cc:808:12
STDERR:     #44 0x5a0b9a in content::ContentMain(content::ContentMainParams
const&) content/app/content_main.cc:19:15
STDERR:     #45 0x4e8682 in main content/shell/app/shell_main.cc:49:10
STDERR:     #46 0x7fb29a0f3ec4 in __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:287:0
STDERR:

[sof, 2015-07-02 07:34:28]

On 2015/07/02 07:31:55, haraken wrote:
> This is the crash trace. It seems that allocatePage is inlined, even though
> allocatePage has NO_SANITIZE_ADDRESS.
> 
> 
> STDERR: =================================================================
> STDERR: ==9380==ERROR: AddressSanitizer: use-after-poison on address
> 0x3c60b9781828 at pc 0x0000004b075d bp 0x7ffc9518aeb0 sp 0x7ffc9518a670
> STDERR: WRITE of size 120792 at 0x3c60b9781828 thread T0 (content_shell)
> STDERR:     #0 0x4b075c in __interceptor_memset ??:0:0
> STDERR:     #1 0x21d2684 in blink::NormalPageHeap::allocatePage()
> third_party/WebKit/Source/platform/heap/Heap.cpp:652:20
> STDERR:     #2 0x21d5591 in blink::NormalPageHeap::outOfLineAllocate(unsigned
> long, unsigned long) third_party/WebKit/Source/platform/heap/Heap.cpp:925:5
> STDERR:     #3 0x505f619 in allocateOnHeapIndex
> third_party/WebKit/Source/platform/heap/Heap.h:1345:12
> STDERR:     #4 0x505f619 in
> allocateHashTableBacking<blink::Member<blink::Resource>,
> WTF::HashTable<blink::Member<blink::Resource>, blink::Member<blink::Resource>,
> WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
> WTF::HashTraits<blink::Member<blink::Resource> >,
> WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
> third_party/WebKit/Source/platform/heap/HeapAllocator.h:89:0
> STDERR:     #5 0x505f619 in
> allocateZeroedHashTableBacking<blink::Member<blink::Resource>,
> WTF::HashTable<blink::Member<blink::Resource>, blink::Member<blink::Resource>,
> WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
> WTF::HashTraits<blink::Member<blink::Resource> >,
> WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
> third_party/WebKit/Source/platform/heap/HeapAllocator.h:94:0
> STDERR:     #6 0x505f619 in allocateTable
> third_party/WebKit/Source/wtf/HashTable.h:984:0
> STDERR:     #7 0x505f619 in WTF::HashTable<blink::Member<blink::Resource>,
> blink::Member<blink::Resource>, WTF::IdentityExtractor,
> WTF::PtrHash<blink::Member<blink::Resource> >,
> WTF::HashTraits<blink::Member<blink::Resource> >,
> WTF::HashTraits<blink::Member<blink::Resource> >,
> blink::HeapAllocator>::rehash(unsigned int, blink::Member<blink::Resource>*)
> third_party/WebKit/Source/wtf/HashTable.h:1141:0
> STDERR:     #8 0x505df92 in shrink
> third_party/WebKit/Source/wtf/HashTable.h:506:25
> STDERR:     #9 0x505df92 in remove
> third_party/WebKit/Source/wtf/HashTable.h:945:0
> STDERR:     #10 0x505df92 in remove
> third_party/WebKit/Source/wtf/HashTable.h:963:0
> STDERR:     #11 0x505df92 in remove
> third_party/WebKit/Source/wtf/HashSet.h:208:0
> STDERR:     #12 0x505df92 in remove
> third_party/WebKit/Source/wtf/HashSet.h:214:0
> STDERR:     #13 0x505df92 in
> blink::MemoryCache::unregisterLiveResource(blink::Resource&)
> third_party/WebKit/Source/core/fetch/MemoryCache.cpp:802:0
> STDERR:     #14 0x507a3d2 in blink::Resource::deleteIfPossible()
> third_party/WebKit/Source/core/fetch/Resource.cpp:646:9
> STDERR:     #15 0x507e185 in
> blink::Resource::unregisterHandle(blink::ResourcePtrBase*)
> third_party/WebKit/Source/core/fetch/Resource.cpp:862:13
> STDERR:     #16 0x50870e8 in ~ResourcePtrBase
> third_party/WebKit/Source/core/fetch/ResourcePtr.h:69:9
> STDERR:     #17 0x50870e8 in ~KeyValuePair
> third_party/WebKit/Source/wtf/HashTraits.h:244:0
> STDERR:     #18 0x50870e8 in deleteAllBucketsAndDeallocate
> third_party/WebKit/Source/wtf/HashTable.h:1012:0
> STDERR:     #19 0x50870e8 in finalize
> third_party/WebKit/Source/wtf/HashTable.h:413:0
> STDERR:     #20 0x50870e8 in ~ConditionalDestructor
> third_party/WebKit/Source/wtf/ConditionalDestructor.h:20:0
> STDERR:     #21 0x50870e8 in ~HashMap
> third_party/WebKit/Source/wtf/HashMap.h:52:0
> STDERR:     #22 0x50870e8 in blink::ResourceFetcher::~ResourceFetcher()
> third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:178:0
> STDERR:     #23 0x21ce3eb in blink::HeapObjectHeader::finalize(unsigned char*,
> unsigned long) third_party/WebKit/Source/platform/heap/Heap.cpp:213:9
> STDERR:     #24 0x21d7c44 in blink::NormalPage::sweep()
> third_party/WebKit/Source/platform/heap/Heap.cpp:1322:13
> STDERR:     #25 0x21d05a2 in blink::BaseHeap::sweepUnsweptPage()
> third_party/WebKit/Source/platform/heap/Heap.cpp:473:9
> STDERR:     #26 0x21d0b2d in blink::BaseHeap::completeSweep()
> third_party/WebKit/Source/platform/heap/Heap.cpp:514:9
> STDERR:     #27 0x2160d81 in blink::ThreadState::completeSweep()
> third_party/WebKit/Source/platform/heap/ThreadState.cpp:1085:13
> STDERR:     #28 0x21df37a in ~SafePointScope
> third_party/WebKit/Source/platform/heap/SafePoint.h:28:13
> STDERR:     #29 0x21df37a in blink::GCScope::~GCScope()
> third_party/WebKit/Source/platform/heap/Heap.cpp:185:0
> STDERR:     #30 0x21dd0fe in
> blink::Heap::collectGarbage(blink::ThreadState::StackState,
> blink::ThreadState::GCType, blink::Heap::GCReason)
> third_party/WebKit/Source/platform/heap/Heap.cpp:2221:1
> STDERR:     #31 0x21df740 in blink::Heap::collectAllGarbage()
> third_party/WebKit/Source/platform/heap/Heap.cpp:2321:9
> STDERR:     #32 0x216c929 in
> blink::ThreadState::safePoint(blink::ThreadState::StackState)
> third_party/WebKit/Source/platform/heap/ThreadState.cpp:1164:5
> STDERR:     #33 0x60ed94 in base::MessageLoop::RunTask(base::PendingTask
const&)
> base/message_loop/message_loop.cc:458:3
> STDERR:     #34 0x60fac4 in DeferOrRunPendingTask
> base/message_loop/message_loop.cc:466:5
> STDERR:     #35 0x60fac4 in base::MessageLoop::DoWork()
> base/message_loop/message_loop.cc:578:0
> STDERR:     #36 0x617ce3 in
> base::MessagePumpDefault::Run(base::MessagePump::Delegate*)
> base/message_loop/message_pump_default.cc:34:21
> STDERR:     #37 0x60db6f in base::MessageLoop::RunHandler()
> base/message_loop/message_loop.cc:422:3
> STDERR:     #38 0x63941b in base::RunLoop::Run() base/run_loop.cc:55:3
> STDERR:     #39 0x60bb28 in base::MessageLoop::Run()
> base/message_loop/message_loop.cc:286:3
> STDERR:     #40 0x80c689d in content::RendererMain(content::MainFunctionParams
> const&) content/renderer/renderer_main.cc:220:7
> STDERR:     #41 0x5a1601 in content::RunZygote(content::MainFunctionParams
> const&, content::ContentMainDelegate*)
content/app/content_main_runner.cc:308:14
> STDERR:     #42 0x5a233f in
> content::RunNamedProcessTypeMain(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> content::MainFunctionParams const&, content::ContentMainDelegate*)
> content/app/content_main_runner.cc:392:12
> STDERR:     #43 0x5a3922 in content::ContentMainRunnerImpl::Run()
> content/app/content_main_runner.cc:808:12
> STDERR:     #44 0x5a0b9a in content::ContentMain(content::ContentMainParams
> const&) content/app/content_main.cc:19:15
> STDERR:     #45 0x4e8682 in main content/shell/app/shell_main.cc:49:10
> STDERR:     #46 0x7fb29a0f3ec4 in __libc_start_main
> /build/buildd/eglibc-2.19/csu/libc-start.c:287:0
> STDERR:

clang will in some cases rewrite such loops (at Heap.cpp:652) into memset(). See
how clearMemory() works around it.

[haraken, 2015-07-02 07:38:59]

On 2015/07/02 07:34:28, sof wrote:
> On 2015/07/02 07:31:55, haraken wrote:
> > This is the crash trace. It seems that allocatePage is inlined, even though
> > allocatePage has NO_SANITIZE_ADDRESS.
> > 
> > 
> > STDERR: =================================================================
> > STDERR: ==9380==ERROR: AddressSanitizer: use-after-poison on address
> > 0x3c60b9781828 at pc 0x0000004b075d bp 0x7ffc9518aeb0 sp 0x7ffc9518a670
> > STDERR: WRITE of size 120792 at 0x3c60b9781828 thread T0 (content_shell)
> > STDERR:     #0 0x4b075c in __interceptor_memset ??:0:0
> > STDERR:     #1 0x21d2684 in blink::NormalPageHeap::allocatePage()
> > third_party/WebKit/Source/platform/heap/Heap.cpp:652:20
> > STDERR:     #2 0x21d5591 in
blink::NormalPageHeap::outOfLineAllocate(unsigned
> > long, unsigned long) third_party/WebKit/Source/platform/heap/Heap.cpp:925:5
> > STDERR:     #3 0x505f619 in allocateOnHeapIndex
> > third_party/WebKit/Source/platform/heap/Heap.h:1345:12
> > STDERR:     #4 0x505f619 in
> > allocateHashTableBacking<blink::Member<blink::Resource>,
> > WTF::HashTable<blink::Member<blink::Resource>,
blink::Member<blink::Resource>,
> > WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
> > WTF::HashTraits<blink::Member<blink::Resource> >,
> > WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
> > third_party/WebKit/Source/platform/heap/HeapAllocator.h:89:0
> > STDERR:     #5 0x505f619 in
> > allocateZeroedHashTableBacking<blink::Member<blink::Resource>,
> > WTF::HashTable<blink::Member<blink::Resource>,
blink::Member<blink::Resource>,
> > WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
> > WTF::HashTraits<blink::Member<blink::Resource> >,
> > WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
> > third_party/WebKit/Source/platform/heap/HeapAllocator.h:94:0
> > STDERR:     #6 0x505f619 in allocateTable
> > third_party/WebKit/Source/wtf/HashTable.h:984:0
> > STDERR:     #7 0x505f619 in WTF::HashTable<blink::Member<blink::Resource>,
> > blink::Member<blink::Resource>, WTF::IdentityExtractor,
> > WTF::PtrHash<blink::Member<blink::Resource> >,
> > WTF::HashTraits<blink::Member<blink::Resource> >,
> > WTF::HashTraits<blink::Member<blink::Resource> >,
> > blink::HeapAllocator>::rehash(unsigned int, blink::Member<blink::Resource>*)
> > third_party/WebKit/Source/wtf/HashTable.h:1141:0
> > STDERR:     #8 0x505df92 in shrink
> > third_party/WebKit/Source/wtf/HashTable.h:506:25
> > STDERR:     #9 0x505df92 in remove
> > third_party/WebKit/Source/wtf/HashTable.h:945:0
> > STDERR:     #10 0x505df92 in remove
> > third_party/WebKit/Source/wtf/HashTable.h:963:0
> > STDERR:     #11 0x505df92 in remove
> > third_party/WebKit/Source/wtf/HashSet.h:208:0
> > STDERR:     #12 0x505df92 in remove
> > third_party/WebKit/Source/wtf/HashSet.h:214:0
> > STDERR:     #13 0x505df92 in
> > blink::MemoryCache::unregisterLiveResource(blink::Resource&)
> > third_party/WebKit/Source/core/fetch/MemoryCache.cpp:802:0
> > STDERR:     #14 0x507a3d2 in blink::Resource::deleteIfPossible()
> > third_party/WebKit/Source/core/fetch/Resource.cpp:646:9
> > STDERR:     #15 0x507e185 in
> > blink::Resource::unregisterHandle(blink::ResourcePtrBase*)
> > third_party/WebKit/Source/core/fetch/Resource.cpp:862:13
> > STDERR:     #16 0x50870e8 in ~ResourcePtrBase
> > third_party/WebKit/Source/core/fetch/ResourcePtr.h:69:9
> > STDERR:     #17 0x50870e8 in ~KeyValuePair
> > third_party/WebKit/Source/wtf/HashTraits.h:244:0
> > STDERR:     #18 0x50870e8 in deleteAllBucketsAndDeallocate
> > third_party/WebKit/Source/wtf/HashTable.h:1012:0
> > STDERR:     #19 0x50870e8 in finalize
> > third_party/WebKit/Source/wtf/HashTable.h:413:0
> > STDERR:     #20 0x50870e8 in ~ConditionalDestructor
> > third_party/WebKit/Source/wtf/ConditionalDestructor.h:20:0
> > STDERR:     #21 0x50870e8 in ~HashMap
> > third_party/WebKit/Source/wtf/HashMap.h:52:0
> > STDERR:     #22 0x50870e8 in blink::ResourceFetcher::~ResourceFetcher()
> > third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:178:0
> > STDERR:     #23 0x21ce3eb in blink::HeapObjectHeader::finalize(unsigned
char*,
> > unsigned long) third_party/WebKit/Source/platform/heap/Heap.cpp:213:9
> > STDERR:     #24 0x21d7c44 in blink::NormalPage::sweep()
> > third_party/WebKit/Source/platform/heap/Heap.cpp:1322:13
> > STDERR:     #25 0x21d05a2 in blink::BaseHeap::sweepUnsweptPage()
> > third_party/WebKit/Source/platform/heap/Heap.cpp:473:9
> > STDERR:     #26 0x21d0b2d in blink::BaseHeap::completeSweep()
> > third_party/WebKit/Source/platform/heap/Heap.cpp:514:9
> > STDERR:     #27 0x2160d81 in blink::ThreadState::completeSweep()
> > third_party/WebKit/Source/platform/heap/ThreadState.cpp:1085:13
> > STDERR:     #28 0x21df37a in ~SafePointScope
> > third_party/WebKit/Source/platform/heap/SafePoint.h:28:13
> > STDERR:     #29 0x21df37a in blink::GCScope::~GCScope()
> > third_party/WebKit/Source/platform/heap/Heap.cpp:185:0
> > STDERR:     #30 0x21dd0fe in
> > blink::Heap::collectGarbage(blink::ThreadState::StackState,
> > blink::ThreadState::GCType, blink::Heap::GCReason)
> > third_party/WebKit/Source/platform/heap/Heap.cpp:2221:1
> > STDERR:     #31 0x21df740 in blink::Heap::collectAllGarbage()
> > third_party/WebKit/Source/platform/heap/Heap.cpp:2321:9
> > STDERR:     #32 0x216c929 in
> > blink::ThreadState::safePoint(blink::ThreadState::StackState)
> > third_party/WebKit/Source/platform/heap/ThreadState.cpp:1164:5
> > STDERR:     #33 0x60ed94 in base::MessageLoop::RunTask(base::PendingTask
> const&)
> > base/message_loop/message_loop.cc:458:3
> > STDERR:     #34 0x60fac4 in DeferOrRunPendingTask
> > base/message_loop/message_loop.cc:466:5
> > STDERR:     #35 0x60fac4 in base::MessageLoop::DoWork()
> > base/message_loop/message_loop.cc:578:0
> > STDERR:     #36 0x617ce3 in
> > base::MessagePumpDefault::Run(base::MessagePump::Delegate*)
> > base/message_loop/message_pump_default.cc:34:21
> > STDERR:     #37 0x60db6f in base::MessageLoop::RunHandler()
> > base/message_loop/message_loop.cc:422:3
> > STDERR:     #38 0x63941b in base::RunLoop::Run() base/run_loop.cc:55:3
> > STDERR:     #39 0x60bb28 in base::MessageLoop::Run()
> > base/message_loop/message_loop.cc:286:3
> > STDERR:     #40 0x80c689d in
content::RendererMain(content::MainFunctionParams
> > const&) content/renderer/renderer_main.cc:220:7
> > STDERR:     #41 0x5a1601 in content::RunZygote(content::MainFunctionParams
> > const&, content::ContentMainDelegate*)
> content/app/content_main_runner.cc:308:14
> > STDERR:     #42 0x5a233f in
> > content::RunNamedProcessTypeMain(std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> > content::MainFunctionParams const&, content::ContentMainDelegate*)
> > content/app/content_main_runner.cc:392:12
> > STDERR:     #43 0x5a3922 in content::ContentMainRunnerImpl::Run()
> > content/app/content_main_runner.cc:808:12
> > STDERR:     #44 0x5a0b9a in content::ContentMain(content::ContentMainParams
> > const&) content/app/content_main.cc:19:15
> > STDERR:     #45 0x4e8682 in main content/shell/app/shell_main.cc:49:10
> > STDERR:     #46 0x7fb29a0f3ec4 in __libc_start_main
> > /build/buildd/eglibc-2.19/csu/libc-start.c:287:0
> > STDERR:
> 
> clang will in some cases rewrite such loops (at Heap.cpp:652) into memset().
See
> how clearMemory() works around it.

Thanks!!! You saved my day...

Just to confirm: Adding NO_SANITIZE_ADDRESS in a cpp file (not a header file) is
a right thing, right?

[sof, 2015-07-02 07:47:27]

On 2015/07/02 07:38:59, haraken wrote:
> On 2015/07/02 07:34:28, sof wrote:
> > On 2015/07/02 07:31:55, haraken wrote:
> > > This is the crash trace. It seems that allocatePage is inlined, even
though
> > > allocatePage has NO_SANITIZE_ADDRESS.
> > > 
> > > 
> > > STDERR: =================================================================
> > > STDERR: ==9380==ERROR: AddressSanitizer: use-after-poison on address
> > > 0x3c60b9781828 at pc 0x0000004b075d bp 0x7ffc9518aeb0 sp 0x7ffc9518a670
> > > STDERR: WRITE of size 120792 at 0x3c60b9781828 thread T0 (content_shell)
> > > STDERR:     #0 0x4b075c in __interceptor_memset ??:0:0
> > > STDERR:     #1 0x21d2684 in blink::NormalPageHeap::allocatePage()
> > > third_party/WebKit/Source/platform/heap/Heap.cpp:652:20
> > > STDERR:     #2 0x21d5591 in
> blink::NormalPageHeap::outOfLineAllocate(unsigned
> > > long, unsigned long)
third_party/WebKit/Source/platform/heap/Heap.cpp:925:5
> > > STDERR:     #3 0x505f619 in allocateOnHeapIndex
> > > third_party/WebKit/Source/platform/heap/Heap.h:1345:12
> > > STDERR:     #4 0x505f619 in
> > > allocateHashTableBacking<blink::Member<blink::Resource>,
> > > WTF::HashTable<blink::Member<blink::Resource>,
> blink::Member<blink::Resource>,
> > > WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
> > > WTF::HashTraits<blink::Member<blink::Resource> >,
> > > WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
> > > third_party/WebKit/Source/platform/heap/HeapAllocator.h:89:0
> > > STDERR:     #5 0x505f619 in
> > > allocateZeroedHashTableBacking<blink::Member<blink::Resource>,
> > > WTF::HashTable<blink::Member<blink::Resource>,
> blink::Member<blink::Resource>,
> > > WTF::IdentityExtractor, WTF::PtrHash<blink::Member<blink::Resource> >,
> > > WTF::HashTraits<blink::Member<blink::Resource> >,
> > > WTF::HashTraits<blink::Member<blink::Resource> >, blink::HeapAllocator> >
> > > third_party/WebKit/Source/platform/heap/HeapAllocator.h:94:0
> > > STDERR:     #6 0x505f619 in allocateTable
> > > third_party/WebKit/Source/wtf/HashTable.h:984:0
> > > STDERR:     #7 0x505f619 in WTF::HashTable<blink::Member<blink::Resource>,
> > > blink::Member<blink::Resource>, WTF::IdentityExtractor,
> > > WTF::PtrHash<blink::Member<blink::Resource> >,
> > > WTF::HashTraits<blink::Member<blink::Resource> >,
> > > WTF::HashTraits<blink::Member<blink::Resource> >,
> > > blink::HeapAllocator>::rehash(unsigned int,
blink::Member<blink::Resource>*)
> > > third_party/WebKit/Source/wtf/HashTable.h:1141:0
> > > STDERR:     #8 0x505df92 in shrink
> > > third_party/WebKit/Source/wtf/HashTable.h:506:25
> > > STDERR:     #9 0x505df92 in remove
> > > third_party/WebKit/Source/wtf/HashTable.h:945:0
> > > STDERR:     #10 0x505df92 in remove
> > > third_party/WebKit/Source/wtf/HashTable.h:963:0
> > > STDERR:     #11 0x505df92 in remove
> > > third_party/WebKit/Source/wtf/HashSet.h:208:0
> > > STDERR:     #12 0x505df92 in remove
> > > third_party/WebKit/Source/wtf/HashSet.h:214:0
> > > STDERR:     #13 0x505df92 in
> > > blink::MemoryCache::unregisterLiveResource(blink::Resource&)
> > > third_party/WebKit/Source/core/fetch/MemoryCache.cpp:802:0
> > > STDERR:     #14 0x507a3d2 in blink::Resource::deleteIfPossible()
> > > third_party/WebKit/Source/core/fetch/Resource.cpp:646:9
> > > STDERR:     #15 0x507e185 in
> > > blink::Resource::unregisterHandle(blink::ResourcePtrBase*)
> > > third_party/WebKit/Source/core/fetch/Resource.cpp:862:13
> > > STDERR:     #16 0x50870e8 in ~ResourcePtrBase
> > > third_party/WebKit/Source/core/fetch/ResourcePtr.h:69:9
> > > STDERR:     #17 0x50870e8 in ~KeyValuePair
> > > third_party/WebKit/Source/wtf/HashTraits.h:244:0
> > > STDERR:     #18 0x50870e8 in deleteAllBucketsAndDeallocate
> > > third_party/WebKit/Source/wtf/HashTable.h:1012:0
> > > STDERR:     #19 0x50870e8 in finalize
> > > third_party/WebKit/Source/wtf/HashTable.h:413:0
> > > STDERR:     #20 0x50870e8 in ~ConditionalDestructor
> > > third_party/WebKit/Source/wtf/ConditionalDestructor.h:20:0
> > > STDERR:     #21 0x50870e8 in ~HashMap
> > > third_party/WebKit/Source/wtf/HashMap.h:52:0
> > > STDERR:     #22 0x50870e8 in blink::ResourceFetcher::~ResourceFetcher()
> > > third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp:178:0
> > > STDERR:     #23 0x21ce3eb in blink::HeapObjectHeader::finalize(unsigned
> char*,
> > > unsigned long) third_party/WebKit/Source/platform/heap/Heap.cpp:213:9
> > > STDERR:     #24 0x21d7c44 in blink::NormalPage::sweep()
> > > third_party/WebKit/Source/platform/heap/Heap.cpp:1322:13
> > > STDERR:     #25 0x21d05a2 in blink::BaseHeap::sweepUnsweptPage()
> > > third_party/WebKit/Source/platform/heap/Heap.cpp:473:9
> > > STDERR:     #26 0x21d0b2d in blink::BaseHeap::completeSweep()
> > > third_party/WebKit/Source/platform/heap/Heap.cpp:514:9
> > > STDERR:     #27 0x2160d81 in blink::ThreadState::completeSweep()
> > > third_party/WebKit/Source/platform/heap/ThreadState.cpp:1085:13
> > > STDERR:     #28 0x21df37a in ~SafePointScope
> > > third_party/WebKit/Source/platform/heap/SafePoint.h:28:13
> > > STDERR:     #29 0x21df37a in blink::GCScope::~GCScope()
> > > third_party/WebKit/Source/platform/heap/Heap.cpp:185:0
> > > STDERR:     #30 0x21dd0fe in
> > > blink::Heap::collectGarbage(blink::ThreadState::StackState,
> > > blink::ThreadState::GCType, blink::Heap::GCReason)
> > > third_party/WebKit/Source/platform/heap/Heap.cpp:2221:1
> > > STDERR:     #31 0x21df740 in blink::Heap::collectAllGarbage()
> > > third_party/WebKit/Source/platform/heap/Heap.cpp:2321:9
> > > STDERR:     #32 0x216c929 in
> > > blink::ThreadState::safePoint(blink::ThreadState::StackState)
> > > third_party/WebKit/Source/platform/heap/ThreadState.cpp:1164:5
> > > STDERR:     #33 0x60ed94 in base::MessageLoop::RunTask(base::PendingTask
> > const&)
> > > base/message_loop/message_loop.cc:458:3
> > > STDERR:     #34 0x60fac4 in DeferOrRunPendingTask
> > > base/message_loop/message_loop.cc:466:5
> > > STDERR:     #35 0x60fac4 in base::MessageLoop::DoWork()
> > > base/message_loop/message_loop.cc:578:0
> > > STDERR:     #36 0x617ce3 in
> > > base::MessagePumpDefault::Run(base::MessagePump::Delegate*)
> > > base/message_loop/message_pump_default.cc:34:21
> > > STDERR:     #37 0x60db6f in base::MessageLoop::RunHandler()
> > > base/message_loop/message_loop.cc:422:3
> > > STDERR:     #38 0x63941b in base::RunLoop::Run() base/run_loop.cc:55:3
> > > STDERR:     #39 0x60bb28 in base::MessageLoop::Run()
> > > base/message_loop/message_loop.cc:286:3
> > > STDERR:     #40 0x80c689d in
> content::RendererMain(content::MainFunctionParams
> > > const&) content/renderer/renderer_main.cc:220:7
> > > STDERR:     #41 0x5a1601 in content::RunZygote(content::MainFunctionParams
> > > const&, content::ContentMainDelegate*)
> > content/app/content_main_runner.cc:308:14
> > > STDERR:     #42 0x5a233f in
> > > content::RunNamedProcessTypeMain(std::__1::basic_string<char,
> > > std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> > > content::MainFunctionParams const&, content::ContentMainDelegate*)
> > > content/app/content_main_runner.cc:392:12
> > > STDERR:     #43 0x5a3922 in content::ContentMainRunnerImpl::Run()
> > > content/app/content_main_runner.cc:808:12
> > > STDERR:     #44 0x5a0b9a in
content::ContentMain(content::ContentMainParams
> > > const&) content/app/content_main.cc:19:15
> > > STDERR:     #45 0x4e8682 in main content/shell/app/shell_main.cc:49:10
> > > STDERR:     #46 0x7fb29a0f3ec4 in __libc_start_main
> > > /build/buildd/eglibc-2.19/csu/libc-start.c:287:0
> > > STDERR:
> > 
> > clang will in some cases rewrite such loops (at Heap.cpp:652) into memset().
> See
> > how clearMemory() works around it.
> 
> Thanks!!! You saved my day...
> 
> Just to confirm: Adding NO_SANITIZE_ADDRESS in a cpp file (not a header file)
is
> a right thing, right?

Yes, that works and is what
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Turning_off...
uses.

I haven't tried putting the attribute decl on the declaration & checked if that
extended to the definition, but it might?

[haraken, 2015-07-02 11:29:52]

Thanks for all the help. It seems we've succeeded in landing this CL:
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Oilpan%...

I'll create a Asan build with Oilpan ToT and update the fuzzer.

[sof, 2015-07-02 11:34:49]

On 2015/07/02 11:29:52, haraken wrote:
> Thanks for all the help. It seems we've succeeded in landing this CL:
>
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Oilpan%...
> 
> I'll create a Asan build with Oilpan ToT and update the fuzzer.

Great, that'd be good.

Do notice that some SVGImage-related instability currently exists,

 https://code.google.com/p/chromium/issues/detail?id=491488#c22

Finalization ordering trouble.