This is because, for msan, the storage stack is chosen as crash stack:

Uninitialized value was stored to memory at
    #0 0x7feb67e97221 in initialize<WTF::HashMapValueTraits<WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::HashTraits<blink::PointerEventFactory::PointerAttributes> >, WTF::KeyValuePair<int, blink::PointerEventFactory::PointerAttributes> > third_party/WebKit/Source/wtf/HashTable.h:783:38
    #1 0x7feb67e97221 in initializeBucket third_party/WebKit/Source/wtf/HashTable.h:802
    #2 0x7feb67e97221 in allocateTable third_party/WebKit/Source/wtf/HashTable.h:1038
    #3 0x7feb67e97221 in WTF::HashTable<int, WTF::KeyValuePair<int, blink::PointerEventFactory::PointerAttributes>, WTF::KeyValuePairKeyExtractor, WTF::IntHash<int>, WTF::HashMapValueTraits<WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::HashTraits<blink::PointerEventFactory::PointerAttributes> >, WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::PartitionAllocator>::rehash(unsigned int, WTF::KeyValuePair<int, blink::PointerEventFactory::PointerAttributes>*) third_party/WebKit/Source/wtf/HashTable.h:1198
    #4 0x7feb67e96aa0 in expand third_party/WebKit/Source/wtf/HashTable.h:1081:12
    #5 0x7feb67e96aa0 in WTF::HashTableAddResult<WTF::HashTable<int, WTF::KeyValuePair<int, blink::PointerEventFactory::PointerAttributes>, WTF::KeyValuePairKeyExtractor, WTF::IntHash<int>, WTF::HashMapValueTraits<WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::HashTraits<blink::PointerEventFactory::PointerAttributes> >, WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::PartitionAllocator>, WTF::KeyValuePair<int, blink::PointerEventFactory::PointerAttributes> > WTF::HashTable<int, WTF::KeyValuePair<int, blink::PointerEventFactory::PointerAttributes>, WTF::KeyValuePairKeyExtractor, WTF::IntHash<int>, WTF::HashMapValueTraits<WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::HashTraits<blink::PointerEventFactory::PointerAttributes> >, WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::PartitionAllocator>::add<WTF::HashMapTranslator<WTF::HashMapValueTraits<WTF::UnsignedWithZeroKeyHashTraits<int>, WTF::HashTraits<blink::PointerEventFactory::PointerAttributes> >, WTF::IntHash<int> >, int const&, blink::PointerEventFactory::PointerAttributes>(int const&, blink::PointerEventFactory::PointerAttributes&&) third_party/WebKit/Source/wtf/HashTable.h:866
    #6 0x7feb67e92fa6 in inlineAdd<const int &, blink::PointerEventFactory::PointerAttributes> third_party/WebKit/Source/wtf/HashMap.h:360:28

As we discussed a while back, the storage stack should be the crash stack for msan job, however the crash state is:
blink::PointerEventManager::setPointerCapture
blink::ElementV8Internal::setPointerCaptureMethodCallback
v8::internal::FunctionCallbackArguments::Call

This will match the first stack instead of storage stack, is this expected?

Honestly I'm not sure what's most useful when working with blame here, but I agree it's not intuitive. I certainly think there are cases where we want to look at frames in stacks other than the initial allocation.

While brainstorming some of the upcoming changes to the ClusterFuzz UI, we realized it might be helpful to stop showing blame results in their current form, and rather have some kind of link that can be clicked next to each frame of the stack trace. This is probably a better way to handle it overall.

Let's lower the priority on this, and put a bit more thought into how we handle blame in general.

as came from discussion at offsite, in clusterfuzz, we should show blame completely as part of stacks next to codesearch links. then we can show for all stack frames.

I think this is a good idea!

I like the idea of showing blames next to each frame in the stack. That won't confuse anyone (or at least less confusing).

Since we all agreed on showing blames next to each frame in the stack in Clusterfuzz UI. I'd mark this as won't fix to close it.