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

Issue 152757 link

Starred by 5 users

Issue metadata

Status: Verified
Owner:
ex-Googler
Closed: Oct 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Sometimes hanging browser using webcam on facebook with OSX Flapper.

Project Member Reported by sh...@chromium.org, Sep 27 2012

Issue description

1) www.facebook.com
2) Add Photo/Video (near top for me)
3) "Webcam"
4) On flash settings, "Allow" and then "Close"

Sometimes I get issue 152622 , but this time I got a UI-thread hang in the browser process.  This is on OSX 10.6.8.  Backtrace from gdb:

#0  0x974e8b42 in semaphore_wait_signal_trap ()
#1  0x974ee646 in pthread_mutex_lock ()
#2  0x9aa987dc in -[QTCaptureSession _buildAndRunGraph] ()
#3  0x94549db3 in _nsnote_callback ()
#4  0x999bf763 in __CFXNotificationPost ()
#5  0x999bf16a in _CFXNotificationPostNotification ()
#6  0x9453ed42 in -[NSNotificationCenter postNotification:] ()
#7  0x94575190 in postQueueNotifications ()
#8  0x999e4dd2 in __CFRunLoopDoObservers ()
#9  0x999a03ea in CFRunLoopRunSpecific ()
#10 0x999a01f1 in CFRunLoopRunInMode ()
#11 0x918bbe04 in RunCurrentEventLoopInMode ()
#12 0x918bbaf5 in ReceiveNextEventCommon ()
#13 0x918bba3e in BlockUntilNextEventMatchingListInMode ()
#14 0x93b88595 in _DPSNextEvent ()
#15 0x93b87dd6 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#16 0x93b4a1f3 in -[NSApplication run] ()
#17 0x05c2b34e in base::MessagePumpNSApplication::DoRun (this=0x17e21be0, delegate=0x17e2cd30) at ../../base/message_pump_mac.mm:574
#18 0x05c2a188 in base::MessagePumpCFRunLoopBase::Run (this=0x17e21be0, delegate=0x17e2cd30) at ../../base/message_pump_mac.mm:169
#19 0x05cbd262 in MessageLoop::RunInternal (this=0x17e2cd30) at ../../base/message_loop.cc:427
#20 0x05cbd11b in MessageLoop::RunHandler (this=0x17e2cd30) at ../../base/message_loop.cc:400
#21 0x05d162f8 in base::RunLoop::Run (this=0xbffff030) at ../../base/run_loop.cc:45
#22 0x07a72aa9 in ChromeBrowserMainParts::MainMessageLoopRun (this=0x17e07bd0, result_code=0x17e07b7c) at ../../chrome/browser/chrome_browser_main.cc:1482
#23 0x071a7a17 in content::BrowserMainLoop::RunMainMessageLoopParts (this=0x17e07b70) at ../../content/browser/browser_main_loop.cc:481
#24 0x071abc2f in (anonymous namespace)::BrowserMainRunnerImpl::Run (this=0x17e08e60) at ../../content/browser/browser_main_runner.cc:122
#25 0x071a57e6 in BrowserMain (parameters=@0xbffff538) at ../../content/browser/browser_main.cc:21
#26 0x01781054 in content::RunNamedProcessTypeMain (process_type=@0xbffff558, main_function_params=@0xbffff538, delegate=0xbffff788) at ../../content/app/content_main_runner.cc:441
#27 0x017824d8 in content::ContentMainRunnerImpl::Run (this=0x17f0a4a0) at ../../content/app/content_main_runner.cc:734  
#28 0x017804c7 in content::ContentMain (argc=3, argv=0xbffff804, delegate=0xbffff788) at ../../content/app/content_main.cc:35
#29 0x00003d3b in ChromeMain (argc=3, argv=0xbffff804) at ../../chrome/app/chrome_main.cc:32
#30 0x7fc00f6b in main (argc=3, argv=0xbffff804) at ../../chrome/app/chrome_exe_main_mac.cc:16

Thread 25 is labelled "MediaStreamDeviceThread", which seems suspicious.  Its backtrace is:

#0  0x97516aa2 in __semwait_signal ()
#1  0x9751675e in _pthread_cond_wait ()
#2  0x975183f8 in pthread_cond_wait$UNIX2003 ()
#3  0x945726b3 in -[NSCondition wait] ()
#4  0x9455fd35 in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] ()
#5  0x9455f8d7 in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:modes:] ()
#6  0x9aa958c7 in -[QTCaptureSession _beginSessionUpdates] ()
#7  0x9aa96ccf in -[QTCaptureSession removeOutput:] ()
#8  0x04df13b5 in -[VideoCaptureDeviceQTKit setCaptureDevice:] (self=0x222de520, _cmd=0x8e5b553, deviceId=0x0) at ../../media/video/capture/mac/video_capture_device_qtkit_mac.mm:96
#9  0x04deed91 in media::VideoCaptureDeviceMac::DeAllocate (this=0x22214b70) at ../../media/video/capture/mac/video_capture_device_mac.mm:108
#10 0x0750eab8 in media_stream::VideoCaptureManager::OnStop (this=0x17ee8dc0, capture_session_id=2, stopped_cb=@0xb9b52690) at ../../content/browser/renderer_host/media/video_capture_manager.cc:281
#11 0x0751ad97 in base::internal::RunnableAdapter<void (media_stream::VideoCaptureManager::*)(int, base::Callback<void ()()>)>::Run (this=0xb9b52710, object=0x17ee8dc0, a1=@0x1561a0e8, a2=@0x1561a0ec) at bind_internal.h:248   
#12 0x0751acab in base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void (media_stream::VideoCaptureManager::*)(int, base::Callback<void ()()>)>, void ()(media_stream::VideoCaptureManager* const&, int const&, base::Callback<void ()()> const&)>::MakeItSo (runnable={method_ = {ptr = 122742784, ptr = 0}}, a1=@0x1561a0e4, a2=@0x1561a0e8, a3=@0x1561a0ec) at bind_internal.h:928
#13 0x0751ac0c in base::internal::Invoker<3, base::internal::BindState<base::internal::RunnableAdapter<void (media_stream::VideoCaptureManager::*)(int, base::Callback<void ()()>)>, void ()(media_stream::VideoCaptureManager*, int, base::Callback<void ()()>), void ()(media_stream::VideoCaptureManager*, int, base::Callback<void ()()>)>, void ()(media_stream::VideoCaptureManager*, int, base::Callback<void ()()>)>::Run (base=0x1561a0d0) at bind_internal.h:1386  
#14 0x0822d23b in base::Callback<void ()()>::Run (this=0xb9b529d4) at callback.h:389
#15 0x05cbda37 in MessageLoop::RunTask (this=0xb9b52e18, pending_task=@0xb9b529c0) at ../../base/message_loop.cc:470
#16 0x05cbdf32 in MessageLoop::DeferOrRunPendingTask (this=0xb9b52e18, pending_task=@0xb9b529c0) at ../../base/message_loop.cc:482
#17 0x05cbe132 in MessageLoop::DoWork (this=0xb9b52e18) at ../../base/message_loop.cc:661
#18 0x05ccdee1 in base::MessagePumpDefault::Run (this=0x222e7f50, delegate=0xb9b52e18) at ../../base/message_pump_default.cc:28
#19 0x05cbd262 in MessageLoop::RunInternal (this=0xb9b52e18) at ../../base/message_loop.cc:427
#20 0x05cbd11b in MessageLoop::RunHandler (this=0xb9b52e18) at ../../base/message_loop.cc:400
#21 0x05d162f8 in base::RunLoop::Run (this=0xb9b52cd8) at ../../base/run_loop.cc:45
#22 0x05cbc516 in MessageLoop::Run (this=0xb9b52e18) at ../../base/message_loop.cc:307
#23 0x05d84682 in base::Thread::Run (this=0x17edc220, message_loop=0xb9b52e18) at ../../base/threading/thread.cc:133
#24 0x05d84833 in base::Thread::ThreadMain (this=0x17edc220) at ../../base/threading/thread.cc:169
#25 0x05d70ce5 in base::(anonymous namespace)::ThreadFunc (params=0x17eda8e0) at ../../base/threading/platform_thread_posix.cc:65
#26 0x97516259 in _pthread_start ()
#27 0x975160de in thread_start ()

Dollars to donuts #5 involves the object and selector in the earlier thread, with waitUntilDone turned on.

I am not smart enough to figure out which thread is blocking the UI thread in all this.  I would HOPE that the media thread's backtrace indicates an attempt for that code to be thread-safe, and it's not holding the lock that the UI thread is pending on.
 
Cc: -sh...@chromium.org
Owner: sh...@chromium.org
Status: Assigned
Labels: Mstone-23 ReleaseBlock-Stable
Given how popular Facebook is, I think this should be a release blocker.

Comment 3 by sh...@chromium.org, Oct 4 2012

Since this is in a debug build which might differ in a number of ways from production, and I haven't seen it again, I think I'd want more supporting evidence before marking it as a release-blocker.  I could have just been very lucky.
Cc: anan...@chromium.org
Anantha, can you help us determine whether / how often this occurs in production builds of M23 with Mac Flapper? (see comment #3)

thanks,
Jeff
Ugh. It looks like -removeOutput: is doing a blocking -performSelectorOnMainThread:... while holding a mutex ... that the main thread is waiting on (in -_buildAndRunGraph:). Total fail (on Apple's part).

AFAICT, doing a blocking replacing the call to -removeOutput: with -performSelectorOnMainThread:@selector(removeOutput:)... "fixes" this.

Comment 6 by sh...@chromium.org, Oct 9 2012

For some reason flash first sets up a 160x120 webcam, then detects a bigger option and stops the smaller one to startup the larger one.  Both teardown and setup are "thread safe" by posting methods to the main (UI) thread.  Unfortunately, some of these methods post a notification which is processed in a future spin of the main event loop, so the main-thread perform returns and a new call can sneak in and post something new before the notification is processed.

If QT is going to bounce through the UI thread anyhow, we should probably hoist the entire setup/teardown to the main thread.
Project Member

Comment 7 by bugdroid1@chromium.org, Oct 10 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=160986

------------------------------------------------------------------------
r160986 | shess@chromium.org | 2012-10-10T00:00:11.377089Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/video/capture/mac/video_capture_device_qtkit_mac.mm?r1=160986&r2=160985&pathrev=160986

[Mac] Remove webcam capture output on main thread to OS race.

When doing webcam setup and teardown on a background thread, QTKit
appears to have a race condition around how it posts work to the main
thread.  This posts part of teardown to the main thread to work around
the problem.

BUG= 152757 
TEST=See bug.


Review URL: https://chromiumcodereview.appspot.com/11094031
------------------------------------------------------------------------

Comment 8 by sh...@chromium.org, Oct 10 2012

Status: Fixed
AFAICT, fixed, but since I was unable to find any evidence of this in the crash system, nor related-looking posts in the bug tracker, it's going to be somewhat hard to really nail it down.

Comment 9 by sh...@chromium.org, Oct 15 2012

Labels: Merge-Requested
As noted, I can't find evidence that this is happening in the wild, but I also cannot find evidence that the patch is causing problems, so I think on balance we should pull it over to M-23.

Comment 10 by kareng@google.com, Oct 15 2012

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 11 by bugdroid1@chromium.org, Oct 15 2012

Labels: -Merge-Approved merge-merged-1271
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=161916

------------------------------------------------------------------------
r161916 | shess@chromium.org | 2012-10-15T19:12:39.047522Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1271/src/media/video/capture/mac/video_capture_device_qtkit_mac.mm?r1=161916&r2=161915&pathrev=161916

Merge 160986 - [Mac] Remove webcam capture output on main thread to OS race.

When doing webcam setup and teardown on a background thread, QTKit
appears to have a race condition around how it posts work to the main
thread.  This posts part of teardown to the main thread to work around
the problem.

BUG= 152757 
TEST=See bug.


Review URL: https://chromiumcodereview.appspot.com/11094031

TBR=shess@chromium.org
Review URL: https://codereview.chromium.org/11155016
------------------------------------------------------------------------
Status: Verified
Working fine in 24.0.12970.0 canary on OS X 10.6.8
Project Member

Comment 13 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Feature-Flash -Feature-Plugins-Pepper -Mstone-23 Cr-Content-Plugins-Flash Cr-Internals M-23 Cr-Content-Plugins-Pepper
Project Member

Comment 14 by bugdroid1@chromium.org, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 15 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash
Project Member

Comment 16 by bugdroid1@chromium.org, Apr 6 2013

Labels: Cr-Internals-Plugins
Project Member

Comment 17 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Plugins-Pepper Cr-Internals-Plugins-Pepper

Sign in to add a comment