It doesn't seem to happen on any Flash, just every Flash that uses a webcam that we've been able to find so far.

Thanks for your help, our business and I'm sure others still do depend on Flash for the time being.

Looks to work if allowscriptaccess is turned off on our swf.

Here are the versions of Chrome that we have seen crashes with:

Windows 10 Pro - Version 1709 - Build 16299.192:
- Version 64.0.3282.119 (Official Build) (64-bit) - 3 computers

MacBook Pro - macOS High Sierra - version 10.13.2:
- Version 66.0.3331.0 (Official Build) canary (64-bit) - 2 computers

MacBook Pro - macOS Sierra - version 10.12.6:
- Version 66.0.3331.0 (Official Build) canary (64-bit) - 1 computer

Here are some more findings:
swf’s fail when accessing the microphone and then crashes the plugin. Seems only related to accessing the microphone.

Upon further inpsection, any swf that starts listening on or trying to use mic data crashes flash immediately.  This happens every single time in Chrome 66 on Mac.  It also happens everytime on Chrome 64 on Windows, and intermitently on Chrome 64 on Mac.  Something definitely broke in the code that allows flash access to the microphone data.

Here is a video of the problem on Chrome Canary 66 on Mac

Deleted: chrome-crash.mov 13.4 MB

	chrome-crash.mov 13.4 MB View Download

Comment 6 I just made references webcamera.io, I am responsible for goreact.com and our recorder has the same problem.  As soon as the swf tries to attach the microphone, it crashes.  Thats why on webcamera.io site, the crash doesn't happen until you click record.  At that moment, their swf tries to attach the mic and it crashes.  On our site it crashes sooner because we access the microphone right away.

Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using latest canary #66.0.3334.0. Issue is not reproducible on chrome stable #64.0.3282.119

Bisect Information:
=====================
Good build: 66.0.3329.0
Bad Build : 66.0.3330.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/68c688b6f1e43dad384bc5d77faaa9231f8639ba..e1d09725275d8bf7607a411c764bff503110a149

From the above change log suspecting below change
Change-Id: If2ece51d217a961f5a9a012621f88101be2a7af7
Reviewed-on: https://chromium-review.googlesource.com/806224

maxmorin@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-66 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

The crashes mentioned in 66.0.3331.0 (Canary for the last few days) should be fixed by https://chromium-review.googlesource.com/c/chromium/src/+/889158, sorry about the mess. This is also tracked in issue 805901. Comment 3 also mentions problems with 64.0.3282.119, which must have another cause.

Since the issues I introduced on Canary are fixed, I'm leaving the rest of this bug to someone else.

The crash id generated while using latest canary #66.0.3334.0 is as follows:
88cb50ea1f8325a8.
The stack trace is as follows:
Thread 0 (id: 413554) CRASHED [EXC_BREAKPOINT / EXC_I386_BPT @ 0x00000001109aa1e0 ] MAGIC SIGNATURE THREAD
Stack Quality
78%Show frame trust levels
0x00000001109aa1e0
(Google Chrome Framework -audio_input_resource.cc:199)
ppapi::proxy::AudioInputResource::SetStreamInfo(base::SharedMemoryHandle, unsigned long, int)
0x00000001109aa04b
(Google Chrome Framework -audio_input_resource.cc:168)
ppapi::proxy::AudioInputResource::OnPluginMsgOpenReply(ppapi::proxy::ResourceMessageReplyParams const&)
0x00000001109aa745
(Google Chrome Framework -callback.h:94)
ppapi::proxy::PluginResourceCallback<IPC::MessageT<PpapiPluginMsg_AudioInput_OpenReply_Meta, std::__1::tuple<>, void>, base::RepeatingCallback<void (ppapi::proxy::ResourceMessageReplyParams const&)> >::Run(ppapi::proxy::ResourceMessageReplyParams const&, IPC::Message const&)
0x0000000110965aee
(Google Chrome Framework -plugin_resource.cc:54)
ppapi::proxy::PluginResource::OnReplyReceived(ppapi::proxy::ResourceMessageReplyParams const&, IPC::Message const&)
0x00000001109654f1
(Google Chrome Framework -plugin_message_filter.cc:116)
ppapi::proxy::PluginMessageFilter::DispatchResourceReply(ppapi::proxy::ResourceMessageReplyParams const&, IPC::Message const&)
0x000000010caab1bb
(Google Chrome Framework -callback.h:65)
base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x000000010cacfe33
(Google Chrome Framework -message_loop.cc:399)
base::MessageLoop::RunTask(base::PendingTask*)
0x000000010cad0338
(Google Chrome Framework -message_loop.cc:411)
base::MessageLoop::DoWork()
0x000000010cad2159
(Google Chrome Framework -message_pump_mac.mm:462)
base::MessagePumpCFRunLoopBase::RunWork()
0x000000010cac3c29
(Google Chrome Framework+ 0x01e52c29)
base::mac::CallWithEHFrame(void () block_pointer)
0x000000010cad1a7e
(Google Chrome Framework -message_pump_mac.mm:438)
base::MessagePumpCFRunLoopBase::RunWorkSource(void*)
0x00007fffa8972320
(CoreFoundation+ 0x000a7320)
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
0x00007fffa895321c
(CoreFoundation+ 0x0008821c)

ben@ - Could you please provide crash id generated at chrome://crashes while using latest stable #64.0.3282.119.
Looping Inhouse team to check the stace trace of the crash id from the reporter from M-64 once its attached here.

Thanks...!!

The above fix isn't available in canary yet, but it will be included in the next one (tomorrow).

I think you guys are right and we are dealing with two separate issues.  The crash behavior on Chrome 64 is different.  Its much easier to reproduce on windows, but it has happened on Mac too.  I attached a video of it.  Its much easier to reproduce on app.goreact.com/login.  You can use these credentials if you want

erik_instructor@goreact.com
password

As you see in the video, choose the Activity on the left called Normal, then click Add Video and then choose record.  We have a modal for an equipment check.  The SWF there gets stuck loading and after 10-15 seconds causes flash plugin to crash.  This behavior doesn't exist on any other browser and wasn't a problem with Chrome 63 either.

Deleted: chrome 64 win.mov 22.2 MB

chrome 64 win.mov 22.2 MB Download

Also, the Chrome 64 crash does not occur every single time.  If the equipment check loads, you can click continue to go the page where the recording will actually occur.  And it loads the same SWF again to record.  It will sometimes fail to load then and crash the same way.  If you repeat the steps and keep trying to add video 50% of the time the SWF will fail to load and Flash will crash.  At least on Windows.  Its harder to get to happen on Mac, but when it does it seems to keep happening each til you kill the browser complete but even then it will still happen.  Thanks so much for your help on these issues guys.

Here is the crash ID for the issue with the latest stable Chrome release 64.0.3282.119: 49c9a979afb5cdf1.

Here is another crash ID for the issue: 6e66b02a44de9bbd.

Crash I'd: 49c9a979afb5cdf1

Stack trace
==========
Thread 0 (id: 564) MAGIC SIGNATURE THREAD
Stack Quality100%Show frame trust levels
0x00007fff47fd0c6a	(ntdll.dll + 0x00090c6a )	NtWaitForMultipleObjects
0x00007fff451613ec	(KERNELBASE.dll + 0x000013ec )	WaitForMultipleObjectsEx
0x00007fff4562106e	(KERNEL32.DLL + 0x0000106e )	WaitForMultipleObjects
0x00007fff2364289a	(chrome_child.dll -waitable_event_win.cc:151 )	base::WaitableEvent::WaitMany(base::WaitableEvent * *,unsigned __int64)
0x00007fff23642398	(chrome_child.dll -wait_set.cc:205 )	mojo::WaitSet::State::Wait(base::WaitableEvent * *,unsigned __int64 *,mojo::Handle *,unsigned int *,MojoHandleSignalsState *)
0x00007fff23641f36	(chrome_child.dll -sync_handle_registry.cc:139 )	mojo::SyncHandleRegistry::Wait(bool const * * const,unsigned __int64)
0x00007fff23641c4c	(chrome_child.dll -ipc_sync_channel.cc:667 )	IPC::SyncChannel::WaitForReply(mojo::SyncHandleRegistry *,IPC::SyncChannel::SyncContext *,bool)
0x00007fff2336e0be	(chrome_child.dll -ipc_sync_channel.cc:628 )	IPC::SyncChannel::Send(IPC::Message *)
0x00007fff255f8b44	(chrome_child.dll -plugin_dispatcher.cc:119 )	ppapi::proxy::PluginDispatcher::Sender::Send(IPC::Message *)
0x00007fff255fe9d1	(chrome_child.dll -plugin_resource.cc:146 )	ppapi::proxy::PluginResource::GenericSyncCall(ppapi::proxy::PluginResource::Destination,IPC::Message const &,IPC::Message *,ppapi::proxy::ResourceMessageReplyParams *)
0x00007fff2566269d	(chrome_child.dll -plugin_resource.h:229 )	ppapi::proxy::PluginResource::SyncCall<IPC::MessageT<PpapiPluginMsg_DeviceEnumeration_EnumerateDevicesReply_Meta>,std::vector<ppapi::DeviceRefData,std::allocator<ppapi::DeviceRefData> > >
0x00007fff25662600	(chrome_child.dll -device_enumeration_resource_helper.cc:61 )	ppapi::proxy::DeviceEnumerationResourceHelper::EnumerateDevicesSync(PP_ArrayOutput const &)
0x00007fff23dd2d3c	(chrome_child.dll -ppb_flash_thunk.cc:163 )	ppapi::thunk::`anonymous namespace'::EnumerateVideoCaptureDevices
This module is sensitive. It must be kept internal to Google!	0x00007fff19de6712	(pepflashplayer.dll -flash.cc:282 )	pp::flash::Flash::EnumerateVideoCaptureDevices(pp::InstanceHandle const &,pp::VideoCapture_Dev const &,std::vector<pp::DeviceRef_Dev,std::allocator<pp::DeviceRef_Dev> > *)

Note:
1. This is a top #2 ppapi Crash on #64.0.3282.119
2. This is a long standing Crash, observing since M59
3. Below are the instances on #64.0.3282.119

64.0.3282.119	0.63%	6216	

Link to the list of the builds
==============================
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20%20AND%20expanded_custom_data.ChromeCrashProto.channel%3D%27%27%20AND%20expanded_custom_data.ChromeCrashProto.ptype%3D%27ppapi%27%20AND%20expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BppPlugin%20hang%5D%20mojo%3A%3AWaitSet%3A%3AState%3A%3AWait%27&sql_dialect=googlesql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#productversion:1000

Thanks!!

The crash on canary is fixed, so I'm merging this to the general Wait hang bug.

Hey @maxmorin so now that you are merging this into 786292 how can we continue to follow up with its progress?  I notice that 786292 is a private issue.  How can we continue to follow the progress?

Ah, I didn't think about that. I'll just undupe it and hand it over to the video capture team since it seems to hang while enumerating video capture devices.

Could some one from media>capture team , please take a look into this issue as it is marked as stable blocker.

Thanks..!

Stable blocker was added for the crash with audio capture, which was fixed. The video capture issue is not a recent regression, and does not have as large impact, so it shouldn't block any release.

Definitely a problem impacting a lot of our users.  Its more prevalent on Windows than on Mac but it happens on all platforms.  Is there anything I can do to help make this a bigger priority?

I'll take a look at this.

A lot of our users are also reporting that flash is crashing since M64. That's happening on windows, mac and linux. Our app uses video and mic capture.

Same here. I was able to reproduce the problem on Mac after thousand users reporting this problem.

We are also having the same issue with M64 and M65. We ended up disallowing Chrome on our platform as we are dependent on video and mic capture.

Yeah same for us. We basically had to show a modal to tell chrome users to be prepared for recording not to work since it crashes so frequently from 64 on.  Glad to hear we aren't the only company having issues with this.

+emircan@, niklase@ FYI.

A hunch I have is that the issues seen on M64 might be caused by a combination of Issue 786292 and  Issue 810980 . 

Issue 786292 says that there is a (long-standing) issue with synchronous IPC calls from Pepper. Based on the crash stacks, it appears that one such call is made when enumerating video capture devices.  Issue 810980  says that on M64, calls to enumerate devices happen much more frequently than they used to. 

I am not 100% that this is a valid theory, because I believe the calls that happen much more frequently are calls from the Browser process to the lower-level video capture stack. Pepper, on the other end, probably asks the Browser process for device enumeration results, so I don't see how that change could increase the frequency of device enumeration calls made from Pepper to the Browser.

Even if the above theory is incorrect, it should be easy to test if there is a connection by starting Chrome 64 with command-line flag --enable-features=MediaDevicesSystemMonitorCaching to force-enable the caching.

Quick update: I tried on M64 with the feature flag for MediaDevicesSystemMonitorCaching set to both disabled and enabled and found the hang can happen in both cases. That seems to suggest that my hunch from above was wrong.

It only happens about 1 out of 8 times on my Windows test machine though. I'll attempt to do a bisect to see if I can narrow down a certain range of changes where the issue started.

Thanks so much @chfremer. Looking forward to what you find out

I completed the bisect. Here are the results:

--
You are probably looking for a change made after 519362 (known good), but no later than 519375 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/72bc6da43e2b5b52a8a32508fc5f777fbc6053e9..68a63508c9a96abe5a95735fe4b0a2ef60e98049
--

The CL range contains https://chromium.googlesource.com/chromium/src/+/2430a3cd0414107f13b785204cdc2c1481b5acc5 which is strong evidence that my hunch from #32 actually wasn't that far off after all. Still not sure why the change in the caching increases the frequency of the issue, but I hope guidou@ may be able to answer this.

As pointed out at https://bugs.chromium.org/p/chromium/issues/detail?id=810980 the problem doesn't seems to happen on M65.

Out of curiosity, since we must alert our users, there's any chance that a fix will be available in the M64 or we should wait for M65 (doesn't looks like a good option to us, since we need to access the camera).

I can reproduce the hang about 33% of the time using app.goreact.com on Linux M66, which still has the cache disabled.
If I enable the cache using --enable-features=MediaDevicesSystemMonitorCaching I cannot reproduce, so it's clear that the cache helps avoid the hang.
It looks like this is caused by bug 786292, but given that we have a mostly reliable repro I'll try to dig in to see if we can find a fix.

I can't see the details of 786292 since its a private issue.  Any info on what that bug is about?

Like #32 says, bug 786292 is a long-standing issue with synchronous IPC calls from Pepper. It is possible that, with the enumeration cache disabled, there is an increased number of those problematic IPC calls, but we haven't confirmed that yet.
I plan to look into this more closely to see if it's the same issue or a different one.

Dupe? https://bugs.chromium.org/p/chromium/issues/detail?id=814629

Re #41: Probably unrelated, since this one here involves Flash, whereas the other one does not.

Lowering priority of this to P2 since the issue is significantly mitigated in M65 which is going to stable soon.
It is very unlikely that a fix will be allowed to be applied to M64 at this point.