New issue
Advanced search Search tips

Issue 710480 link

Starred by 8 users

Issue metadata

Status: Duplicate
Merged: issue 708074
Owner: ----
Closed: Apr 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression


Participants' hotlists:
Hotlist-1


Sign in to add a comment

Browser Tab crashes with Aw, Snap! on Blackboard Session

Reported by abhina...@gmail.com, Apr 11 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.54 Safari/537.36

Steps to reproduce the problem:
1. Join https://apollodemo01.bbcollab.com/collab/ui/session/guest/8A5D356DFE1118DC9196240915B8CD23 as Chrome (any version), say A.
2. Join same session as Chrome 58 Beta user, say B.
3. Start mic, cam on B.
4. From A, go to the bottom right, Collaborate Panel > Share Content > Share Application > Just An Application. This will show Add to Chrome button, install Desktop Sharing extension (URL: https://chrome.google.com/webstore/detail/desktop-sharing/ajojghojfapedgfkjmhchgblmjfanggo)
5. Once extension is installed, Reload the session.
6. Open Collaborate Panel > Share Content > Share Application > Just An Application.
7. Select an application that can be resized (say Skype) and start AppShare.
8. Now, start resizing the shared application, e.g. Skype and continue to do so for over 20 seconds or so.

What is the expected behavior?
AppShare resizing on A's end should be reflected at B without issues.

What went wrong?
B's browser tab where the Blackboard Session was running crashes if A continuously resizes shared application.

Crashed report ID: Crash ID 0219cee4-27d3-4668-b787-46d9d11cdd1f (Server ID: 859f304c80000000)

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? Yes Google Chrome Version 57.0.2987.133 (64-bit)

Chrome version: 58.0.3029.54  Channel: beta
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 25.0 r0
 

Comment 1 by abhina...@gmail.com, Apr 11 2017

This is also reproducible with Chrome Version 59.0.3068.1 canary (64-bit) besides Chrome version: 58.0.3029.54  Channel: beta

Comment 2 by abhina...@gmail.com, Apr 11 2017

To confirm it's not to do with latest Mac OS Beta that I have, I tested and was able to reproduce Aw, Snap! crash on OS Version: OS X 10.10.5 with Chrome version: 58.0.3029.54  Channel: beta

This doesn't seem to be Mac specific, I also managed to reproduce it on a Windows 7 Enterprise (Service Pack 1) with Version: 58.0.3029.54 beta (64-bit)

Comment 3 by meh...@chromium.org, Apr 11 2017

Cc: rsesek@chromium.org
Thanks for the crash id.

Comment 4 by rsesek@chromium.org, Apr 11 2017

Mergedinto: 708074
Status: Duplicate (was: Unconfirmed)

Comment 5 by abhina...@gmail.com, Apr 17 2017

@rsesek - Will the fix for #708074 land in Chrome 58 Stable?

Comment 6 by rsesek@chromium.org, Apr 17 2017

I just un-restricted the bug. It's not yet fixed, but it may get merged when it does.
Note that a crash has also been reproduced using similar steps with the screen sharing functionality of Jitsi Meet (https://meet.jit.si), so it's not specific to Blackboard Collaborate.

Comment 8 by abhina...@gmail.com, Apr 19 2017

@rsesek - Is it possible for you to confirm if the crash on Crash ID ffb38ee6-e08b-4764-870d-6f163d29b037 (Server ID: 1e18893210000000) is same as the one I reported originally on this ticket, Crash ID 0219cee4-27d3-4668-b787-46d9d11cdd1f (Server ID: 859f304c80000000)

Comment 9 by rsesek@chromium.org, Apr 19 2017

Yes, those are the same crash stacks:

0x000000010a7afde3	(Google Chrome Framework -__tree:148 )	webrtc::video_coding::FrameBuffer::NextFrame(long long, std::__1::unique_ptr<webrtc::video_coding::FrameObject, std::__1::default_delete<webrtc::video_coding::FrameObject> >*)
0x000000010a7a3d2f	(Google Chrome Framework -video_receive_stream.cc:478 )	webrtc::internal::VideoReceiveStream::Decode()
0x0000000109b61616	(Google Chrome Framework -platform_thread.cc:231 )	rtc::PlatformThread::Run()
0x0000000109b61568	(Google Chrome Framework -platform_thread.cc:138 )	rtc::PlatformThread::StartThread(void*)
0x00007fffa28a7aaa	(libsystem_pthread.dylib + 0x00003aaa )	
0x00007fffa28a79f6	(libsystem_pthread.dylib + 0x000039f6 )	
0x00007fffa28a7220	(libsystem_pthread.dylib + 0x00003220 )	
0x0000000109b6155f	(Google Chrome Framework -platform_thread.cc:118 )	rtc::PlatformThread::~PlatformThread()
Aw, Snap! Crash is no longer reproducible on Chrome Canary, Version 60.0.3077.0 (Official Build) canary (64-bit)

I tried on PC which had Version 60.0.3076.0 and found that it was becoming unresponsive and eventually crashing, probably need to wait for Version 60.0.3077.0 for PC.
Chrome Canary, Version 60.0.3077.0 (Official Build) canary (64-bit) mentioned above in Comment 10 was tested on Mac (on OS Version: OS X 10.12.1 and OS X 10.10.5)
I re-tested on PC with Chrome Canary 60.0.3078.0 and found that it is no longer crashing with Aw, Snap!
@reseek I'm experiencing a crash that I believe is caused by the same issue, it's Crash ID 16a14dec-9163-4eff-9bbe-794a239b0d2a (Server ID: 4b4fb47590000000), can you confirm that this is the same issue?
Re: #13: No, that's issue 682945 which is now fixed.
@rsesek I'm unable to see issue 682945, is it private? Should the fix have made it's way into Chrome 58.0.3029.81? I'm still seeing the crash on 58.0.3029.81 but it's not crashing in Chrome Canary 60.0.3078.0.
58.0.3029.96 --> Still experiencing webrtc related issues
Occasionally rather than an "aww snap", the entire browser crashes making it difficult to capture a report without tracing actively. More likely to occur during video calls, testing over jitsi meet.

Comment 17 by cbro...@g.uafs.edu, May 22 2017

What is the timetable on a fix for this issue?

Sign in to add a comment