The ffmpeg library which I used it https://github.com/BrianJFeldman/ffmpeg.js.wasm .
The attachment video is how the crash happened.

Deleted: 2018-10-14_21-20-58.mp4 2.8 MB

	2018-10-14_21-20-58.mp4 2.8 MB View Download

I reproduced the crash and it is an OOM... See crash report 71f551b7856ae228

The exact same example works correctly in FireFox so over to the WASM team to verify that it is just an OOM and not a memory leak.

+clemensh, who's been triaging many OOMs of late. Clemens, do you have a straightforward playbook for triaging OOMs (e.g., whether they're due to Liftoff code)?

Don't have playbook for triaging such OOMs. If they happen within wasm allocations or reservations, we can sometimes fall back to trying another GC before crashing because of OOM. But in this case it it an OOM while trying to grow an array.

This is the stack trace:

[...]
#6  0x00007fccb1fb122a in v8::internal::Heap::FatalProcessOutOfMemory(char const*) (this=0x3a7b6d295040, location=0x7fccb13349cf "invalid array length") at ../../v8/src/heap/heap.cc:4814
#7  0x00007fccb1f65e9a in v8::internal::Factory::AllocateRawFixedArray(int, v8::internal::PretenureFlag) (this=0x3a7b6d295020, length=169220804, pretenure=v8::internal::NOT_TENURED) at ../../v8/src/heap/factory.cc:173
#8  0x00007fccb1f65794 in v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object*, v8::internal::PretenureFlag) (this=0x3a7b6d295020, map_root_index=v8::internal::RootIndex::kFixedArrayMap, length=169220804, filler=0x205c765004d9, pretenure=v8::internal::NOT_TENURED) at ../../v8/src/heap/factory.cc:298
#9  0x00007fccb1f67cf7 in v8::internal::Factory::NewUninitializedFixedArray(int, v8::internal::PretenureFlag) (this=0x3a7b6d295020, length=169220804, pretenure=v8::internal::NOT_TENURED) at ../../v8/src/heap/factory.cc:411
#10 0x00007fccb1e70573 in v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedSmiElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)0> >::ConvertElementsWithCapacity(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::FixedArrayBase>, v8::internal::ElementsKind, unsigned int, unsigned int, unsigned int, int) (object=..., old_elements=..., from_kind=v8::internal::ElementsKind::PACKED_SMI_ELEMENTS, capacity=169220804, src_index=0, dst_index=0, copy_size=-2) at ../../v8/src/elements.cc:851
#11 0x00007fccb1e704b6 in v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedSmiElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)0> >::ConvertElementsWithCapacity(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::FixedArrayBase>, v8::internal::ElementsKind, unsigned int) (object=..., old_elements=..., from_kind=v8::internal::ElementsKind::PACKED_SMI_ELEMENTS, capacity=169220804) at ../../v8/src/elements.cc:830
#12 0x00007fccb1e6e52c in v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedSmiElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)0> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) (this=0x3a7b67f3e480, object=..., index=112813858) at ../../v8/src/elements.cc:966
#13 0x00007fccb24cd13e in v8::internal::__RT_impl_Runtime_GrowArrayElements(v8::internal::Arguments, v8::internal::Isolate*) (args=..., isolate=0x3a7b6d295020) at ../../v8/src/runtime/runtime-array.cc:676
#14 0x00007fccb24cccc7 in v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object**, v8::internal::Isolate*) (args_length=2, args_object=0x7fcc55b0d290, isolate=0x3a7b6d295020) at ../../v8/src/runtime/runtime-array.cc:664
#15 0x00007fccb2dd8b15 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit () at /usr/local/google/home/clemensh/chromium/src/out/Debug/./libv8.so
#16 0x00001443ed7b8016 in  ()
[...]

Note that it fails with "invalid array length", i.e. it tries to allocate an array of >=1GB. I wonder if we shouldn't throw a RangeError there instead of crashing?

Additionally I get this fragmented GC output. Might be another bug.

<--- Last few GCs --->
il[1:0x1feec4ba9020]    34288 ms: Mark-sweep 963.7 (968.3) -> 580.9 (585.7) MB, 24.6 / 0.1 ms  (+ 6.3 ms in 5 steps since start of marking, biggest step 4.2 ms, walltime since start of marking 557 ms) (average mu = 0.969, current mu = 0.966) finalize increm[1:0x1feec4ba9020]    35788 ms: Mark-sweep 1442.3 (1446.4) -> 867.8 (872.6) MB, 55.6
/ 0.1 ms  (+ 5.1 ms in 6 steps since start of marking, biggest step 4.7 ms, walltime since start of marking 856 ms) (average mu = 0.964, current mu = 0.961) finalize incr


Adding GC people to look at both issues.

Not sure why we do crash with OOM instead of RangeError. There are others uses of the throw macro in factory, so that should actually be possible.

As for the truncated output: That's part of the fatal OOM. There's a ringbuffer keeping trace gc output and we just dump that one on OOM in certain scenarios.

Actually, we should probably throw a RangeError at some higher level. The FixedArray allocation needs to have a hard failure as that one is also internally where we do not have JS exception handling available.

Assigning to you for know, and changing title, as this is not a WebAssembly issue.

We checked back with mths@ on the issue and it's probably nice to throw when called from elements code.

Given that this is also working as intended (I do like the RangeErrors though) I'll lower the priority and handle it at a later point.