Webview crashes on Slack calls

[srirambv]

Description

Webview crashes on Slack calls

Steps to Reproduce

1. Login to Slack
2. Ask some one in team to call you
3. Answer the call and be angry as web view crashes

Actual result:

Webview crashes on Slack calls

Expected result:

Should not cause webview crash

Reproduces how often:

Easily reproduces

Brave version (about:brave info)

Release build and possibly packaged build as well

Reproducible on current release:

Website problems only:

• Does the issue resolve itself when disabling Brave Shields?
• Is the issue reproducible on the latest version of Chrome?

Additional Information

cc: @bbondy

[srirambv]

Update: Slack tab keeps crashing at random times. Usually the page becomes unresponsive and then goes into an infinite reload. I keep getting the notification sounds of new messages but doesn't allow to load. Have to open slack in another tab to start using it.

Also experienced this on release build
https://bravesoftware.slack.com/archives/C7VLGSR55/p1530881407000151

[emerick]

Repro'ed on my Windows machine. Looking at the crash dump, it's dying when trying to initialize the WebRTC voice engine, specifically when cricket::WebRTCVoiceEngine::Init calls webrtc::adm_helpers::Init.

[emerick]

It's trying to log an error message when it fails: "[3880:12236:0720/091113.186:ERROR:adm_helpers.cc(73)] Failed to query stereo recording." The crash seems to happen in the call to fwrite, due to an invalid parameter. Hard to see exactly what went haywire, as I'm lacking source code at that point. Almost seems like the WebRTC logging isn't quite configured right and is dying when trying to access the log file.

[garrettr]

I tried to reproduce this on macOS with a debug build but Slack kept crashing before I could even message someone to initiate a test call. I will file issues for the crashes I observed in the debug build, and attempt to repro again with a release build.

[emerick]

@bbondy mentioned that this could be due to fingerprinting-related patches to RTC.

Ran two tests today against the latest master. With "Fingerprinting Protection" set to "Block All Fingerprinting", Brave hung (but did not crash) and then Slack showed a "trouble connecting to the server" page. With the setting switched to "Allow All Fingerprinting", the call went through perfectly fine.

Similar results when visiting https://bravesoftware.slack.com/help/test/calls. "Block All Fingerprinting" led to test failures for microphone and camera. "Allow All Fingerprinting" led to all tests passing.

[emerick]

@garrettr You were possibly crashing in debug mode due to this problematic DCHECK that was recently commented out in Chromium's trunk (but is still enabled in our version of the code):

https://chromium-review.googlesource.com/c/chromium/src/+/1083675

Just an FYI, as I recently ran into it too...

[emerick]

@srirambv I ran a few more tests this morning and I think this is working as expected now, but let me know what you think. There is no longer any crash (possibly due to the move to C68). Everything works as expected when shields are down. When shields are up, the call isn't able to proceed and Slack issues an error message about network connectivity. Not sure there is a much better response we could have in that situation yet still prevent browser fingerprinting.

[srirambv]

Still happens on 1532e51 when running using npm run start Release. Both Slack tab and the call tab crashes once the call is received. But running src/out/Release/brave.exe doesn't crash and allows to answer the call with shields up (default settings).

[emerick]

Seems related to the logging crash, which I'm investigating further now.

[emerick]

So here's my take: This is crashing because we're launching from a non-standard shell (i.e., not cmd.exe). WebRTC tries to log to stderr when it encounters any warnings/errors and non-standard shells are most likely not equipped to properly deal with stderr in this way. This would explain why we see the problem when running with npm run start Release yet not when running brave.exe directly with no additional parameters.

Also, I was able to repro the problem in the latest Chrome by launching Chrome via chrome.exe --enable-logging --v=2 from a non-standard shell (a Git for Windows prompt, in my case). On connecting to a call in Slack, Chrome promptly crashed.

I think the solution in this particular case is to only run this type of test from cmd.exe or by double-clicking on the executable in Windows Explorer. Any other methods are probably unsafe/unreliable.

[emerick]

Spoke with @srirambv and we think the non-native shell is the root cause as discussed above, so closing this issue. Will reopen if we ever encounter this while using cmd.exe.

[srirambv]

Verification Passed on

Brave	0.55.6 Chromium: 70.0.3538.16 (Official Build) dev (64-bit)
Revision	16ed95b41bb05e565b11fb66ac33c660b721f778-refs/branch-heads/3538@{#306}
OS	Linux

• Verified calling another user and disconnecting the call, no crash
• Verified calling another user and user disconnect the call , no crash
• Verified receiving call from other user and disconnecting the call, no crash
• Verified receiving call from other user and user disconnect the call , no crash

Went through verification using the following build under macOS 10.13.6 x64 - PASSED

Brave	0.55.6 Chromium: 70.0.3538.16 (Official Build) dev (64-bit)
Revision	16ed95b41bb05e565b11fb66ac33c660b721f778-refs/branch-heads/3538@{#306}

Verification PASSED on

Brave	0.55.6 Chromium: 70.0.3538.16 (Official Build) dev (64-bit)
Revision	16ed95b41bb05e565b11fb66ac33c660b721f778-refs/branch-heads/3538@{#306}
OS	Windows