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

Issue 615043 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
tommi@chromium.org
ossu@chromium.org
dalecur...@chromium.org
█ olka@chromium.org
maxmorin@chromium.org
solenberg@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

RendererWebAudioDeviceImpl may use invalid render frame ID when creating sink

Project Member Reported by grunell@chromium.org, May 26 2016 
By accident, when hacking the code for testing purposes, I hit the following DCHECK:

[1:1:0526/164623:FATAL:audio_message_filter.cc(80)] Check failed: render_frame_id > 0 (-2 vs. 0)
#0 0x7f64f11a683e base::debug::StackTrace::StackTrace()
#1 0x7f64f12096cf logging::LogMessage::~LogMessage()
#2 0x7f64ebd9b117 content::AudioMessageFilter::CreateAudioOutputIPC()
#3 0x7f64ebd9392e content::(anonymous namespace)::NewOutputDevice()
#4 0x7f64ebd930a3 content::AudioDeviceFactory::NewFinalAudioRendererSink()
#5 0x7f64ebd93220 content::AudioDeviceFactory::NewAudioRendererSink()
#6 0x7f64ebde555a content::RendererWebAudioDeviceImpl::start()

When there's no render frame, RendererWebAudioDeviceImpl::start() uses MSG_ROUTING_NONE as render frame ID, but that is not accepted when creating the audio output IPC.

AudioOutputIPCImpl stores the render frame ID as const at creation, so the DCHECK there is valid.
Project Member

Comment 1 by sheriffbot@chromium.org, May 29 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 2 by grunell@chromium.org, May 29 2017

Cc: maxmorin@chromium.org ossu@chromium.org
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
Maybe someone feels like taking a look? I don't know when this can happen and what would happen in production if it does. If I understand my own report, this is only for WebAudio.

Comment 3 by maxmorin@chromium.org, May 29 2017

Components: Blink>WebAudio
I see this large and relevant-looking CL landed after this issue was reported: https://codereview.chromium.org/2501863003, so this issue might not reproduce anymore? Maybe we should just close it?

Only tangentially related, passing the frame id as a callback in https://cs.chromium.org/chromium/src/content/renderer/media/renderer_webaudiodevice_impl.cc?l=121 looks unnecessary, as the frame id is already known at construction time. Similarly for the device_params_cb.

Comment 4 by hongchan@chromium.org, Oct 11 2017 

How do I reproduce this? I don't see any DCHECK failure shown above. If this is not reproducible any more, we should close it.

Comment 5 by grunell@chromium.org, Oct 12 2017

Status: WontFix (was: Available)
The path is still the same as the original call stack, from [1] to [2], and the DCHECK is still there. However, the |frame_id_| set in RendererWebAudioDeviceImpl is now DCHECK'd to not be MSG_ROUTING_NONE[3]. So this issue is no more, maybe the CL in #3 did it.

[1] https://cs.chromium.org/chromium/src/content/renderer/media/renderer_webaudiodevice_impl.cc?dr=CSs&q=RendererWebAudioDeviceImpl::start&sq=package:chromium&l=165
[2] https://cs.chromium.org/chromium/src/content/renderer/media/audio_message_filter.cc?dr=CSs&sq=package:chromium&l=75
[3] https://cs.chromium.org/chromium/src/content/renderer/media/renderer_webaudiodevice_impl.cc?dr=CSs&sq=package:chromium&l=132
►

Sign in to add a comment