New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 616380 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Jun 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

video_WebRtcMediaRecorder started failing on 8372.0.0 on ARM devices

Project Member Reported by wuchengli@chromium.org, Jun 1 2016

Issue description

Cc: jansson@chromium.org tnakamura@chromium.org avkodipelli@chromium.org
Labels: -Type-Bug -Pri-2 M-53 OS-Chrome Pri-1 Type-Bug-Regression
Owner: ----
cpaulin@ is no longer w/ WebRTC team. 

jansson@ would you be able to help?

Looks like the browser is crashing during the test. 

Traceback (most recent call last):
  File "/usr/local/autotest/common_lib/test.py", line 804, in _call_test_function
    return func(*args, **dargs)
  File "/usr/local/autotest/common_lib/test.py", line 461, in execute
    dargs)
  File "/usr/local/autotest/common_lib/test.py", line 347, in _call_run_once_with_retry
    postprocess_profiled_run, args, dargs)
  File "/usr/local/autotest/common_lib/test.py", line 376, in _call_run_once
    self.run_once(*args, **dargs)
  File "/usr/local/autotest/tests/video_WebRtcMediaRecorder/video_WebRtcMediaRecorder.py", line 81, in run_once
    self.launch_recorder_test('testStartStopAndRecorderState')
  File "/usr/local/autotest/tests/video_WebRtcMediaRecorder/video_WebRtcMediaRecorder.py", line 41, in launch_recorder_test
    if not self.is_test_completed():
  File "/usr/local/autotest/tests/video_WebRtcMediaRecorder/video_WebRtcMediaRecorder.py", line 71, in is_test_completed
    sleep_interval=1)
  File "/usr/local/autotest/common_lib/site_utils.py", line 846, in poll_for_condition
    value = condition()
  File "/usr/local/autotest/tests/video_WebRtcMediaRecorder/video_WebRtcMediaRecorder.py", line 64, in test_done
    test_progress = self.tab.EvaluateJavaScript(TEST_PROGRESS)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/browser/web_contents.py", line 187, in EvaluateJavaScript
    expr, context_id=None, timeout=timeout)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/browser/web_contents.py", line 215, in EvaluateJavaScriptInContext
    expr, context_id=context_id, timeout=timeout)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_backend.py", line 32, in inner
    return func(inspector_backend, *args, **kwargs)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_backend.py", line 203, in EvaluateJavaScript
    return self._runtime.Evaluate(expr, context_id, timeout)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_runtime.py", line 45, in Evaluate
    res = self._inspector_websocket.SyncRequest(request, timeout)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_websocket.py", line 110, in SyncRequest
    res = self._Receive(timeout)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_websocket.py", line 166, in _Receive
    self._HandleNotification(result)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_websocket.py", line 179, in _HandleNotification
    self._domain_handlers[domain_name](result)
  File "/usr/local/telemetry/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_backend.py", line 288, in _HandleInspectorDomainNotification
    raise exception
DevtoolsTargetCrashException: Devtools target crashed
Cc: phoglund@chromium.org m...@chromium.org
Owner: rohi...@chromium.org
rohitbm@ - can someone in CrOS run this test locally to get a stack trace? In a randomly selected status log from one of the failing runs [1], I see this:
  Stack Trace:
  ********************************************************************************
  	Cannot get stack trace on CrOS
  ********************************************************************************

Also, I'm cc'ing miu@ as a shot-in-the-dark because I see references to CLs associated with bug 612084 in https://chromium.googlesource.com/chromium/src/+log/53.0.2746.0..53.0.2748.0?pretty=fuller&n=10000. That bug isn't actually viewable to me, but the gist I'm getting from the CL descriptions is that it is tracking some sort of crash.

[1] http://go/zisfv
Owner: tnakamura@chromium.org
This is a Chrome renderer crash caused by testStartStopAndRecorderState test. Sorry, I don't have a local setup to symbolicate dump files. 

http://cs/chromeos_public/src/third_party/autotest/files/client/site_tests/video_WebRtcMediaRecorder/loopback_mediarecorder.html

Can someone in WebRTC run this JS locally on an ARM device using the latest M53 build?

// Tests that the MediaRecorder's stop() function will effectively cause the
// |state| to be 'inactive' and that a 'stop' event is fired.
function testStartStopAndRecorderState() {
  var stopEventReceived = false;
  navigator.mediaDevices.getUserMedia(DEFAULT_CONSTRAINTS)
      .then(function(stream) {
        return createAndStartMediaRecorder(stream, DEFAULT_RECORDER_MIME_TYPE);
      })
      .then(function(recorder) {
        recorder.onstop = function(event) {
          stopEventReceived = true;
          assertEquals('inactive', recorder.state);
        };
        recorder.stop();
      })
      .then(function() {
        return waitFor('Make sure the stop event was received',
            function() {
              return stopEventReceived;
            });
      })
      .catch(function(err) {
        return failTest(err.toString());
      })
      .then(function() {
        reportTestSuccess();
      });
}
Owner: srcv@chromium.org
The lack of a stack trace is kind of frustrating, especially since this appears to crash on a variety of ARM devices (i.e. this doesn't appear to be a flaky test). I've filed  bug 616953  to track some way to improve that. :)

srcv@, can you install a newer M53 CrOS build (8372.0.0 or newer) on an ARM device, and then do the following:

1) chrome://flags -> enable-experimental-web-platform-features -> enable
2) click the Relaunch Now button
3) Open https://cdn.rawgit.com/tednakamura/tedtest/master/crbug616380/loopback_mediarecorder.html
4) Open the js console, type testStartStopAndRecorderState();
5) Press Enter (accept the gUM prompt if you see one)

If that results in a crash, please try to get a crash ID as usual.

Comment 5 by srcv@chromium.org, Jun 3 2016

Owner: tnakamura@chromium.org
Followed instructions in comment#4 and observed that chrome crashes on device Pi with M53 53.0.2754.0 / 8406.0.0 dev

Crash IDs:
afdda75c00000000
cb1e8f5a00000000

Cc: -m...@chromium.org niklase@chromium.org
Owner: emir...@chromium.org
Thanks srcv@! 

The stack trace in those reports is incomplete due to some missing symbols, but I at least see a reference to VEAEncoder::~VEAEncoder from video_track_recorder.cc, so I'm sending this to emircan@. Also note that VEAEncoder::~VEAEncoder shows up twice in the trace; I have no idea why.

Thread 0 CRASHED [SIGSEGV @ 0x00000000 ] MAGIC SIGNATURE THREAD
0xb2d1462e	(chrome -bind_internal.h:186 )	base::internal::Invoker<base::IndexSequence<0u>, base::internal::BindState<base::internal::RunnableAdapter<bool (CloudPrintProxyService::*)()>, void(CloudPrintProxyService*), base::internal::UnretainedWrapper<CloudPrintProxyService> >, base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<bool (CloudPrintProxyService::*)()> >, void()>::Run
0xb1e2fdb7	(libpthread-2.19.so -lowlevellock.c:46 )	__lll_lock_wait
0xb1e4ebbd	(libgcc_s.so.1 + 0x00016bbd )	
0xb4cfb073	(chrome -video_track_recorder.cc:400 )	VEAEncoder::~VEAEncoder
0xb1e2fdb7	(libpthread-2.19.so -lowlevellock.c:46 )	__lll_lock_wait
0xb1e2c98d	(libpthread-2.19.so -pthread_mutex_unlock.c:66 )	__pthread_mutex_unlock_usercnt
0xb674cc76	(chrome + 0x041d7c76 )	_fini
0xb29c669b	(chrome -message_loop.cc:475 )	base::MessageLoop::DoWork
0xb659077a	(chrome + 0x0401b77a )	_fini
0xb2d1461b	(chrome -media_capture_devices_dispatcher.cc:438 )	MediaCaptureDevicesDispatcher::UpdateCapturingLinkSecured
0xb6ae24be	(chrome + 0x0456d4be )	_fini
0xb674cc76	(chrome + 0x041d7c76 )	_fini
0xb4cfb073	(chrome -video_track_recorder.cc:400 )	VEAEncoder::~VEAEncoder
0xb2ffd889	(chrome -safe_math_impl.h:211 )	base::internal::CheckedMul<long long int>
0xb1e4ebbd	(libgcc_s.so.1 + 0x00016bbd )	
0xb29c6db1	(chrome -message_pump_default.cc:33 )	base::MessagePumpDefault::Run
0xb2fead49	(chrome -run_loop.cc:35 )	base::RunLoop::Run
0xb2fda06b	(chrome -message_loop.cc:294 )	base::MessageLoop::Run
0xb2ffae77	(chrome -thread.cc:254 )	base::Thread::ThreadMain
0xb2ff9575	(chrome -platform_thread_posix.cc:70 )	ThreadFunc
0xb2ff9533	(chrome + 0x00a84533 )	base::PlatformThread::SetCurrentThreadPriority(base::ThreadPriority)
0xb1e296b9	(libpthread-2.19.so -pthread_create.c:311 )	start_thread
Cc: mcasas@chromium.org
Status: Fixed (was: Assigned)
I landed this CL to disable VEa usage on CrOS. It should fix the issues. 
https://codereview.chromium.org/2035593002/
Cc: mshe...@chromium.org haddowk@chromium.org emir...@chromium.org wuchengli@chromium.org
 Issue 604581  has been merged into this issue.
This has been fixed but not sure how.

PASS: 8409.0.0	53.0.2757.0		
FAIL: 8406.0.0	53.0.2754.0
Status: Verified (was: Fixed)
Re #9; The CL I pointed to in #7 landed within that range.
Cc: -mshe...@chromium.org

Sign in to add a comment