verwaest@ could you please look into this.please feel free to re-assigned back if needed. thanks in advance !

This does not look like a V8 regression at all. The V8 changes in the regression range are unrelated.

I didn't see any calls into the Presentation API in the test case nor any revisions in the revision range that would have affected the behavior of the Presentation API.  I suspect some other bug has corrupted the navigator supplement map.   Regardless, we can take a look.

Bin, do you mind taking a look at the test case and see if it repros?  Not sure where it is calling into navigator.presentation.receiver.

Sure. Looking into this.

Derek helped looking into this, and we suspect that frame() is pointing to a corrupted frame which causes the crash.

PresentationReceiver* Presentation::receiver() {
  PresentationController* controller = PresentationController::from(*frame());
  ..
}

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/presentation/Presentation.cpp?rcl=0&l=51

mlamouri@, is it possible that we may access presentation.receiver attribute after frame() has been freed? Is there any annotation or inheritence prevents us from doing this?

I think it's possible, yes. ::setDefaultRequest() checks that frame() isn't null. I would assume that this check would fix your crash.

The scenario I have in mind is the following:
- you create an iframe, you hold `navigator.presentation` to `p`
- kill and gc the iframe
- `p` is still accessible but the frame is destroyed so frame() is probably null now

mlamouri@ Thanks a lot, we will add null check for frame().

(cannot find mini dump file though) The callstack shows crash deep in hashtable.h,  which seems to suggest frame() is not null but pointing to corrupt memory (freed) when accessing presentation.receiver attr. If frame() is null, we may crash earlier than that when we are dereferencing frame(). If that's the case, will the crash still be there even if we have null checks?

PresentationController* controller = PresentationController::from(*frame());

Crash stack:
WTF::HashTable<blink::LayoutBox const *,WTF::KeyValuePair<blink::LayoutBox const *,unsigned int>,WTF::KeyValuePairKeyExtractor,WTF::PtrHash<blink::LayoutBox const >,WTF::HashMapValueTraits<WTF::HashTraits<blink::LayoutBox const *>,WTF::HashTraits<unsigned int> >,WTF::HashTraits<blink::LayoutBox const *>,WTF::PartitionAllocator>::lookup<WTF::IdentityHashTranslator<WTF::PtrHash<blink::LayoutBox const > >,blink::LayoutBox const *>+0x6 [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/wtf/hashtable.h @ 987]
WTF::HashTable<char const *,WTF::KeyValuePair<char const *,blink::Member<blink::Supplement<blink::Navigator> > >,WTF::KeyValuePairKeyExtractor,WTF::PtrHash<char const >,WTF::HashMapValueTraits<WTF::HashTraits<char const *>,WTF::HashTraits<blink::Member<blink::Supplement<blink::Navigator> > > >,WTF::HashTraits<char const *>,blink::HeapAllocator>::lookup+0x829c3da1 (Inline Function @ 03213dd9) (CONV: thiscall) [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/wtf/hashtable.h @ 745]
WTF::HashTable<char const *,WTF::KeyValuePair<char const *,blink::Member<blink::Supplement<blink::Navigator> > >,WTF::KeyValuePairKeyExtractor,WTF::PtrHash<char const >,WTF::HashMapValueTraits<WTF::HashTraits<char const *>,WTF::HashTraits<blink::Member<blink::Supplement<blink::Navigator> > > >,WTF::HashTraits<char const *>,blink::HeapAllocator>::lookup+0x829c3da1 (Inline Function @ 03213dd9) (CONV: thiscall) [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/wtf/hashtable.h @ 745]
WTF::HashMap<char const *,blink::Member<blink::Supplement<blink::Navigator> >,WTF::PtrHash<char const >,WTF::HashTraits<char const *>,WTF::HashTraits<blink::Member<blink::Supplement<blink::Navigator> > >,blink::HeapAllocator>::get+0x829c3da7 (Inline Function @ 03213dd9) (CONV: thiscall) [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/wtf/hashmap.h @ 548]
blink::Supplementable<blink::Navigator>::requireSupplement+0x829c3da7 (Inline Function @ 03213dd9) (CONV: thiscall) [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/platform/supplementable.h @ 140]
blink::Supplement<blink::Navigator>::from+0x18 (FPO: [Non-Fpo]) (CONV: cdecl) [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/platform/supplementable.h @ 105]
blink::PresentationController::from+0x1a (FPO: [Non-Fpo]) (CONV: cdecl) [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/modules/presentation/presentationcontroller.cpp @ 41]
blink::Presentation::receiver+0xd [c:/b/c/b/win_syzyasan_lkgr/src/third_party/webkit/source/modules/presentation/presentation.cpp @ 52]
v8::internal::ExternalCallbackScope::ExternalCallbackScope+0x47 [c:/b/c/b/win_syzyasan_lkgr/src/v8/src/vm-state-inl.h @ 66]
v8::internal::FunctionCallbackArguments::Call+0xbe [c:/b/c/b/win_syzyasan_lkgr/src/v8/src/api-arguments.cc @ 20]
v8::internal::`anonymous namespace::HandleApiCallHelper<0>+0x1f2 (FPO: [Non-Fpo]) (CONV: cdecl) [c:/b/c/b/win_syzyasan_lkgr/src/v8/src/builtins/builtins-api.cc @ 108]
v8::internal::Builtins::InvokeApiFunction+0x1fe (FPO: [Non-Fpo]) (CONV: cdecl) [c:/b/c/b/win_syzyasan_lkgr/src/v8/src/builtins/builtins-api.cc @ 211]
v8::internal::Object::GetPropertyWithAccessor+0x2b5 (FPO: [Non-Fpo]) (CONV: cdecl) [c:/b/c/b/win_syzyasan_lkgr/src/v8/src/objects.cc @ 1362]
v8::internal::Object::GetProperty+0x12f (FPO: [Non-Fpo]) (CONV: cdecl) [c:/b/c/b/win_syzyasan_lkgr/src/v8/src/objects.cc @ 998]

I think we need to tie the lifetime of navigator.presentation to the browsing context (frame), otherwise how can we implement receiver or defaultRequest without running into lifetime issues?

Cannot repro this issue with "asan-linux-debug-425020" linux build or "asan-win32-release-425020" windows build locally with 1000 runs. Will land the fix directly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1399b5bdf21388b0b1a77c01473431988035e587

commit 1399b5bdf21388b0b1a77c01473431988035e587
Author: zhaobin <zhaobin@chromium.org>
Date: Thu Nov 17 02:40:28 2016

[Presentation API] check if frame() is null before accessing presentation.receiver attr

We have seen random crashes when accessing navigator.presentation.receiver attribute. We suspect that is caused by accessing attribute after frame() get destroyed. Add null check and only access frame() for the first time.

BUG= 657479 

Review-Url: https://codereview.chromium.org/2502633005
Cr-Commit-Position: refs/heads/master@{#432713}

[modify] https://crrev.com/1399b5bdf21388b0b1a77c01473431988035e587/third_party/WebKit/Source/modules/presentation/Presentation.cpp

Rerun fuzz test after the fix and it does not crash.

[2016-11-22 17:57:38] clusterfuzz-windows-0047: Progression task in-progress: Testing r425020:r433807.
[2016-11-22 17:57:52] clusterfuzz-windows-0047: Progression task errored out: Known crash revision 425020 did not crash.
[2016-11-22 17:57:52] clusterfuzz-windows-0047: Progression task errored out: Test case appears to be flaky.