Able to reproduce the issue on the latest canary(57.0.2935.0) on Mac OS 10.11.6(Crash id: 81c6c89f00000000), Windows-10(Crash id: 50e5710f00000000)

Regressed in M-57.

Last good build: 56.0.2924.0
First bad build: 57.0.2925.0

Changelog: https://chromium.googlesource.com/chromium/src/+log/acdbb3c267d8d4ea19d0faf4ef34b5179f3c58fa..cfd33cef4f1a51ba612d28504c6f76e1dfe588a6

wolenetz@: Could you please take a look at this and help in routing this to appropriate owner. Unable to bisect this further with the bisect tool inside the ffmpeg roll.

Stack trace(50e5710f00000000):
===============================
Thread 10 CRASHED [EXCEPTION_ACCESS_VIOLATION_WRITE @ 0x00000000 ] MAGIC SIGNATURE THREAD
Stack Quality63%Show frame trust levels
0x00007ffff789c91c	(chrome_child.dll -audioarray.h:61 )	blink::AudioArray<float>::allocate(unsigned __int64)
0x00007ffff789c3e9	(chrome_child.dll -audiochannel.h:58 )	blink::AudioChannel::AudioChannel(unsigned __int64)
0x00007ffff789c2cc	(chrome_child.dll -audiobus.cpp:64 )	blink::AudioBus::AudioBus(unsigned int,unsigned __int64,bool)
0x00007ffff789d08b	(chrome_child.dll -audiobus.cpp:55 )	blink::AudioBus::create(unsigned int,unsigned __int64,bool)
0x00007ffff78ac1d1	(chrome_child.dll -webaudiobus.cpp:40 )	blink::WebAudioBus::initialize(unsigned int,unsigned __int64,double)
0x00007ffff7f70f85	(chrome_child.dll -audio_decoder.cc:57 )	content::DecodeAudioFileData(blink::WebAudioBus *,char const *,unsigned __int64)
0x00007ffff789d415	(chrome_child.dll -audiobus.cpp:724 )	blink::decodeAudioFileData(char const *,unsigned __int64)
0x00007ffff789d17e	(chrome_child.dll -audiobus.cpp:754 )	blink::createBusFromInMemoryAudioFile(void const *,unsigned __int64,bool,float)
0x00007ffff7d7df90	(chrome_child.dll -asyncaudiodecoder.cpp:81 )	blink::AsyncAudioDecoder::decodeOnBackgroundThread(blink::DOMArrayBuffer *,float,blink::AudioBufferCallback *,blink::AudioBufferCallback *,blink::ScriptPromiseResolver *,blink::BaseAudioContext *)
0x00007ffff7d7dd68	(chrome_child.dll -bind_internal.h:339 )	base::internal::Invoker<base::internal::BindState<void (*)(blink::DOMArrayBuffer *,float,blink::AudioBufferCallback *,blink::AudioBufferCallback *,blink::ScriptPromiseResolver *,blink::BaseAudioContext *),blink::CrossThreadPersistent<blink::DOMArrayBuffer>,float,blink::CrossThreadPersistent<blink::AudioBufferCallback>,blink::CrossThreadPersistent<blink::AudioBufferCallback>,blink::CrossThreadPersistent<blink::ScriptPromiseResolver>,blink::CrossThreadPersistent<blink::BaseAudioContext> >,void >::Run(base::internal::BindStateBase *)
0x00007ffff63b0f21	(chrome_child.dll -callback.h:68 )	base::internal::RunMixin<base::Callback<void ,0,0> >::Run( ?? )
0x00007ffff63b0e6a	(chrome_child.dll -worker_pool_win.cc:30 )	base::`anonymous namespace'::WorkItemCallback
0x00007ff839b98f6b	(ntdll.dll + 0x00008f6b )	
0x00007ff839b98f2d	(ntdll.dll + 0x00008f2d )	
0x00007ff839bbd41f	(ntdll.dll + 0x0002d41f )	
0x00007ff839bbe12f	(ntdll.dll + 0x0002e12f )	
0x00007ff839b98e3f	(ntdll.dll + 0x00008e3f )	
0x00007ff839bbba6f	(ntdll.dll + 0x0002ba6f )	
0x00007ff839b98e3f	(ntdll.dll + 0x00008e3f )	

+ dalecurtis@ since wolenetz@ is OOO.

Thank you!

Clip is reporting an infinite duration since it's a live stream clip. We're incorrectly trying to use that value for the allocation, which fails on a CHECK() and intentionally crashes.

This doesn't seem to work on stable, where the value is reported as zero. Unless I'm misunderstanding, I think it's impossible for this to work as WebAudio decodeAudioFileData() is currently specified; since it decodes everything in one go and needs to know the total size upfront ... and this code seems to want to stream from the media recorder into WebAudio.

I suspect there's a different mechanism required to connect MediaRecorder to WebAudio... but why do this? Why not just connect the microphone directly to WebAudio?

+mcasas

Actually I am misunderstanding, it does record the full sample then send it to WebAudio. My other statements are correct though, the file has no duration information and on stable we report 0 for the total duration because of this; while on canary we correctly report unknown duration which is incorrectly treated as the duration.

To fix this MediaRecorder needs to write the correct duration bits into the muxed container and we should ensure AV_NOPTS_VALUE durations are ignored by AudioFileReader. 

Fix for crash here https://codereview.chromium.org/2537603003

=> mcasas@ for any MR changes.

#10: there is already  https://crbug.com/642012  that proposes
making webm files seekable (at the same time adding the timing
information), but it's nontrivial due to, well, not knowing in
advance how long the recording is going to take :-)
Let's keep this bug for the crash, and star the mentioned one
if interested in this functionality.

Marked blocking  issue 591845 . Once the crash fix has landed, please request merge to M56, assign to me to get the merge complete (which can only happen after the main roll in  issue 591845  is also merged to M56).

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

commit f7f6a8ef3024fe72f77d74426e69a8f3fa54c3f5
Author: dalecurtis <dalecurtis@chromium.org>
Date: Wed Nov 30 01:52:45 2016

Fail decodeAudioFileData() when duration is unknown.

This API as currently written can only work with streams of a
known duration, so explicitly fail instead of misinterpreting
a massive 64-bit value as the actual duration.

BUG= 668849 
TEST=new unittest and layout test.

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

[modify] https://crrev.com/f7f6a8ef3024fe72f77d74426e69a8f3fa54c3f5/media/filters/audio_file_reader.cc
[modify] https://crrev.com/f7f6a8ef3024fe72f77d74426e69a8f3fa54c3f5/media/filters/audio_file_reader_unittest.cc
[modify] https://crrev.com/f7f6a8ef3024fe72f77d74426e69a8f3fa54c3f5/third_party/WebKit/LayoutTests/webaudio/decode-audio-data-basic-expected.txt
[modify] https://crrev.com/f7f6a8ef3024fe72f77d74426e69a8f3fa54c3f5/third_party/WebKit/LayoutTests/webaudio/decode-audio-data-basic.html

Users experienced this crash on the following builds:

Mac Canary 57.0.2937.0 -  1.52 CPM, 1 reports, 1 clients (signature blink::AudioArray<float>::allocate)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Since ffmpeg roll made it to M56, this needs to be merged there to. 

Your change meets the bar and is auto-approved for M56 (branch: 2924)

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

commit 06a5c7686f5355f8b173060567d033e552cbebbd
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Dec 01 01:18:51 2016

Merge M56: "Fail decodeAudioFileData() when duration is unknown."

This API as currently written can only work with streams of a
known duration, so explicitly fail instead of misinterpreting
a massive 64-bit value as the actual duration.

BUG= 668849 
TEST=new unittest and layout test.

Review-Url: https://codereview.chromium.org/2537603003
Cr-Commit-Position: refs/heads/master@{#435118}
(cherry picked from commit f7f6a8ef3024fe72f77d74426e69a8f3fa54c3f5)

Review URL: https://codereview.chromium.org/2540373002 .

Cr-Commit-Position: refs/branch-heads/2924@{#231}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/06a5c7686f5355f8b173060567d033e552cbebbd/media/filters/audio_file_reader.cc
[modify] https://crrev.com/06a5c7686f5355f8b173060567d033e552cbebbd/media/filters/audio_file_reader_unittest.cc
[modify] https://crrev.com/06a5c7686f5355f8b173060567d033e552cbebbd/third_party/WebKit/LayoutTests/webaudio/decode-audio-data-basic-expected.txt
[modify] https://crrev.com/06a5c7686f5355f8b173060567d033e552cbebbd/third_party/WebKit/LayoutTests/webaudio/decode-audio-data-basic.html