Issue 605786  has been merged into this issue.

Is this V8 GC or Oilpan?

This is a kind of OOM. The allocation size is too huge (larger than INT_MAX).

Let's not simply dismiss this bug. The crash is happening in the V8 bindings for ImageBitmapOptions (V8ImageBitmapOptions::toImpl), during the checks that the incoming strings are valid enums. It looks like during the construction of a string for an exception message that the OOM happens. How could that happen while allocating a simple string?

It's crashing because |colorspaceConversion| passed by V8 is >2 GB. V8 binding needs to check that the string is one of "none" and "default". There V8 binding needs to convert the passed-in string to a WTF::String. If the string is too huge, it causes OOM.

How can the colorspaceConversion string possibly be that large? It's not even passed from the JavaScript level. (See src/third_party/webgl/src/sdk/tests/js/tests/tex-image-and-sub-image-with-image-bitmap-utils.js). Is this uninitialized data? xidachen@ wrote these tests and should be able to help too.

Yeah, that's a good point.

yukishiino@: Maybe you have a bandwidth to take a look at this?

kbr@: I looked at the test, and the failure is strange. It should not be uninitialized. The colorspaceConversion has a default value "default" when the ImageBitmapOptions is constructed. This is what the constructor looks like:

ImageBitmapOptions::ImageBitmapOptions()
{
    setColorspaceConversion(String("default"));
    setImageOrientation(String("none"));
    setPremultiplyAlpha(String("default"));
}

Could it be related to how our bindings work with a dictionary idl?

Yes, there's almost certainly a bug, and it's almost certainly in the bindings and how dictionary types and enums work.

Could you let us know where is the test code?  I don't know where conformance_textures_image_bitmap_from_blob_tex_2d_rgba_rgba_unsigned_short_4_4_4_4 is defined.

Reading src/third_party/webgl/src/sdk/tests/js/tests/tex-image-and-sub-image-with-image-bitmap-utils.js , it seems the tests are always passing the valid enumb values.  However, the stack trace at #0 looks like that we're handling an invalid enum value.  Quite strange.

From my first investigation, there is nothing clear.  No reason so far to think that there is a bug in dictionary types or enums.

Is this issue constantly reproducible?  Seeing https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Release%20%28Intel%29?numbuilds=200 , the issue seems not reproducible.  Then, it's hard to find the cause.

yukishiino@:
The test is located here:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webgl/src/sdk/tests/conformance/textures/image/tex-2d-rgba-rgba-unsigned_short_4_4_4_4.html&q=tex-2d-rgba-rgba-unsigned_short_4_4_4_4.html&sq=package:chromium&l=1

It basically directly uses this js file:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webgl/src/sdk/tests/js/tests/tex-image-and-sub-image-2d-with-image-bitmap-from-blob.js&q=tex-image-and-sub-image-2d-with-image-bitmap-from-blob.js&sq=package:chromium&l=1

And that uses the src/third_party/webgl/src/sdk/tests/js/tests/tex-image-and-sub-image-with-image-bitmap-utils.js.

Sorry for any confusion. The GPU tests are documented in https://www.chromium.org/developers/testing/gpu-testing .

You can run this test, for example, by building the Release browser (or Debug, then change the command line below) and running:

./content/test/gpu/run_gpu_test.py webgl_conformance --browser=release --story-filter=conformance_textures_image_bitmap_from_blob_tex_2d_rgba_rgba_unsigned_short_4_4_4_4

or, to run a larger subset of the tests:

./content/test/gpu/run_gpu_test.py webgl_conformance --browser=canary --story-filter=conformance_textures_image_bitmap_from_blob*

You might need the additional arguments

--pageset-repeat=100 --max-failures=1

to catch the first failure most easily.

Let me know if you have difficulty reproducing the bug.

I'm not able to repro on my local Linux.  I know the crash was reported on Mac.  But it seems not reproducible on Mac, too, seeing https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Release%20%28Intel%29?numbuilds=200 .

Considering that the test is passing the valid enum values, but the stacktrace shows that the binding layer is handling an invalid enumb value, I'm afraid that someone broke memory content.  There wouldn't be any gain from investigating this issue.

May I close this issue?  Or any advice?

yukishiino@: since there's no way to reproduce the problem, yes, let's close this as not reproducible. We need to stay on top of such potential memory stomps in the future to keep the product stable.