nzolghadr@, could you please take a look or suggest another owner?

I've seen you fixed a similar bug 615361.

Yup. That would be me. I'll take a look.

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

mmoroz@ I was looking at it. I don't know what change introduced this problem. Looking at the
https://chromium.googlesource.com/chromium/src/+log/627ddfd0de197d67567a15191f654b8835408bce..d24d249700deef0ed63bf12ebb6af3b28f8225fb?pretty=fuller
and
https://chromium.googlesource.com/v8/v8/+log/2ebd9e2f994359273155d63a199eed6fb7786e14..3414d38b079043d0b9f2e9a1dbb8bd35ec22e8db?pretty=fuller

non-of my changes are related to this part of the code. So I'm not sure what change to revert. Since that was the area of the code that I wrote at first a few months back I thought I might be able to see the problem.
Looking at the example that reproduce this problem I wasn't sure how that js could possibly get there. The stack trace seems weird as well as that function is not accessible directly expect through another function but that function was not in the stack trace. So I'm a little stuck on this. 

M53 beta launch is coming soon.Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix before 6:00 PM PST, Monday (07/18/16). Thank you.

mmoroz@ I failed to reproduce this problem locally on the tip of the tree. I passed the same parameters and also served the file over my local http server. Still no crash. Note that I can see the crash when I ran it with your binary with the same parameters.
Looking at the change list
https://chromium.googlesource.com/chromium/src/+log/627ddfd0de197d67567a15191f654b8835408bce..d24d249700deef0ed63bf12ebb6af3b28f8225fb?pretty=fuller

None of the changes in pointer event section touches this area remotely. So I'm not sure what's the way forward here.

Have you used release build when tried to reproduce?

I did use release. Should I have used a debug build? It wasn't mentioned in the bug so I was not sure.

It's correct to use Release build. I've just kicked "redo Fixed" job and also trying to reproduce locally.

CF is able to reproduce it with recent build.

When trying to reproduce with my local builds, I'm getting other crashes. Firslty there was a linking problem with libfreetype -> had to rebuild it separately ("third_party/freetype2:freetype2"), now getting another errors:


$ MSAN_OPTIONS=symbolize=1:coverage=0 ~/Projects/new/chromium/src/out/Release/chrome --js-flags="--expose-gc" --no-first-run --use-gl=osmesa --disable-gl-drawing-for-tests http://127.0.0.1:8000/fuzz-twister-http-test_bug2704141467865030.8.html
Uninitialized bytes in __interceptor_strchr at offset 0 inside [0x7ffcffdf6e50, 1)
==96968==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f88b38fae2b  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2ae2b)
    #1 0x7f88b38faeb6  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2aeb6)
    #2 0x7f88b38ffef5 in g_type_register_fundamental (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2fef5)
    #3 0x7f88b38e173b  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x1173b)
    #4 0x7f88b38db5d1 in _init (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0xb5d1)
    #5 0x7f88b4a0a109 in call_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:78
    #6 0x7f88b4a0a1f2 in call_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:36
    #7 0x7f88b4a0a1f2 in _dl_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:126
    #8 0x7f88b49fb309  (/lib64/ld-linux-x86-64.so.2+0x1309)

  Uninitialized value was created by an allocation of '__p.i.i' in the stack frame of function '_ZNKSt3__16locale9use_facetERNS0_2idE'
    #0 0x7f88b481ae20 in std::__1::locale::use_facet(std::__1::locale::id&) const buildtools/third_party/libc++/trunk/src/locale.cpp:593

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2ae2b) 
Exiting

Looks like we need to build more libs to reproduce the issue locally.

I don't seem to see the same crashes. Here is what I did on 941bc7e523e5502a6d2211d0c0837504e0bfc5dd.

ninja -C out/Release chrome
MSAN_OPTIONS=symbolize=1:coverage=0 ./out/Release/chrome --js-flags="--expose-gc" --no-first-run --use-gl=osmesa --disable-gl-drawing-for-tests http://web-platform.test:8000/pointerevents/fuzz-twister-http-test_bug2704141467865030.8.html


But I only see this in the console with no crash:
** Message: Remote error from secret service: org.freedesktop.Secret.Error.IsLocked: Cannot create an item in a locked collection
** Message: Remote error from secret service: org.freedesktop.Secret.Error.IsLocked: Cannot create an item in a locked collection
[91872:91895:0718/120415:ERROR:native_backend_libsecret.cc(382)] Libsecret add raw login failed: Cannot create an item in a locked collection

M53 beta launch is next week.Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix before 6:00 PM PST, Friday (07/22/16). Thank you.

Without the ability to reproduce locally (see #13 above), it seems impossible to me to discover-then-fix the cause by this Friday.

I'm afraid sheriffbot's label changes were a hiccup - this is still a blocker for Friday's M53. 

mmoroz@ - thoughts on next steps?

I've tried to reproduce locally - no luck again:


mmoroz@mmoroz0:~/fuzzing/chrome$ MSAN_OPTIONS=symbolize=0:coverage=0 ./chrome --js-flags="--expose-gc" --no-first-run --use-gl=osmesa --disable-gl-drawing-for-tests http://127.0.0.1:8000/fuzz-twister-http-test_bug2704141467865030.8.html
Uninitialized bytes in __interceptor_strchr at offset 0 inside [0x7ffe8497c8e0, 1)
==135313==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f4c15a01e2b  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2ae2b)
    #1 0x7f4c15a01eb6  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2aeb6)
    #2 0x7f4c15a06ef5  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2fef5)
    #3 0x7f4c159e873b  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x1173b)
    #4 0x7f4c159e25d1  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0xb5d1)
    #5 0x7f4c16b11109  (/lib64/ld-linux-x86-64.so.2+0x10109)
    #6 0x7f4c16b111f2  (/lib64/ld-linux-x86-64.so.2+0x101f2)
    #7 0x7f4c16b02309  (/lib64/ld-linux-x86-64.so.2+0x1309)

  Uninitialized value was created by an allocation of '__p.i.i' in the stack frame of function '_ZNKSt3__16locale9use_facetERNS0_2idE'
    #0 0x7f4c16921e20  (/usr/local/google/home/mmoroz/Projects/new/chromium/src/out/Release/./libc++.so+0x188e20)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2ae2b) 
Exiting
mmoroz@mmoroz0:~/fuzzing/chrome$ 
mmoroz@mmoroz0:~/fuzzing/chrome$ 
mmoroz@mmoroz0:~/fuzzing/chrome$ 
mmoroz@mmoroz0:~/fuzzing/chrome$ MSAN_OPTIONS=symbolize=1:coverage=0 ./chrome --js-flags="--expose-gc" --no-first-run --use-gl=osmesa --disable-gl-drawing-for-tests http://127.0.0.1:8000/fuzz-twister-http-test_bug2704141467865030.8.html
Uninitialized bytes in __interceptor_strchr at offset 0 inside [0x7fff9ae990d0, 1)
==135519==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7fc23f3c9e2b  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2ae2b)
    #1 0x7fc23f3c9eb6  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2aeb6)
    #2 0x7fc23f3ceef5 in g_type_register_fundamental (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2fef5)
    #3 0x7fc23f3b073b  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x1173b)
    #4 0x7fc23f3aa5d1 in _init (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0xb5d1)
    #5 0x7fc2404d9109 in call_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:78
    #6 0x7fc2404d91f2 in call_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:36
    #7 0x7fc2404d91f2 in _dl_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:126
    #8 0x7fc2404ca309  (/lib64/ld-linux-x86-64.so.2+0x1309)

  Uninitialized value was created by an allocation of '__p.i.i' in the stack frame of function '_ZNKSt3__16locale9use_facetERNS0_2idE'
    #0 0x7fc2402e9e20 in std::__1::locale::use_facet(std::__1::locale::id&) const buildtools/third_party/libc++/trunk/src/locale.cpp:593

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2ae2b) 
Exiting

Will try to figure out a way to reproduce, but probably not soon.

Max, did you build chrome with "use_prebuilt_instrumented_libraries=true" ?

https://www.chromium.org/developers/testing/memorysanitizer

ClusterFuzz has detected this issue as fixed in range 407415:407421.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6521494654156800

Fuzzer: inferno_twister_custom_bundle
Job Type: linux_msan_chrome
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  blink::PointerEventManager::setPointerCapture
  blink::ElementV8Internal::setPointerCaptureMethodCallback
  v8::internal::FunctionCallbackArguments::Call
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_chrome&range=403806:403830
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_chrome&range=407415:407421

Minimized Testcase (2.70 Kb): https://cluster-fuzz.appspot.com/download/AMIfv96btPvPy9P1m1wbR-K_eUB4VefBNl9q5ov4uNgtzKI78vNsJzbI9YDnmQ6MKKXe28OylBlhxMBPuJvtP-BrzTkrS9QSR5v9HtTkcb6Ls5wsXyglKnA5W23HnmgyaTD01wuevbeZ6ewCJGXCvoqd1HZz1u5jyA?testcase_id=6521494654156800

Additional requirements: Requires HTTP

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Regarding #c26, Oliver, I've tried to reproduced without that, thanks for pointing this out. Now I tried:

$ GYP_DEFINES='msan=1 use_prebuilt_instrumented_libraries=1' gclient sync
$ GYP_DEFINES='msan=1 use_prebuilt_instrumented_libraries=1' gclient runhooks

then build with "use_prebuilt_instrumented_libraries=true".

In that case it doesn't crash at all neither for regressed version nor the fixed one.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I actually can reproduce the crash locally. 

I didn't do anything special. I downloaded the build and the localreproconfig (https://cluster-fuzz.appspot.com/localreproconfig?key=6521494654156800). And, then, I ran `python src/tools/on_demand/run_gestures_on_device_local.py --config ~/Downloads/config_6521494654156800.zip --build ~/Downloads/msan-chained-origins-linux-release-403874/`.

Something odd is going on.

This should be fixed by now. There was another similar  issue 647024  that I managed to reproduce it locally as well and that fixed it.