Business impact: Customer will have a prod-launch at the end of Aug (in 10 days). This is their single biggest deploy in the past 5 years with 11k units across entire palm beach school in Florida. This bug will impact 30% of their annual revenue.

Customer previously opened a ticket addressing such issue (issue ID=872312), but was marked duplicated and closed with no resolution. Please escalate and allow the communication to be initiated. We are looking to understand the root cause, workaround, remediation and potential roadmap on patches.

Lan could you look at this one?

Sure, can we reproduce the crash on a windows touch device?

reporter, can you elaborate a little more on in_range flag? Is that a Chrome flag or some config related to SMART BOARD?

yijingmeng@ we don't have a SMART BOARD device here. It might take sometime until we order and get one. Until then I'm not sure how we can address the issue as the deadline seems to be tight?

I just want to be clear that the bigger problem seems to be that Chrome becomes unresponsive.  Chrome does crash and it would be good to fix that too.  I just tried today's canary build and it still has the same problems, 70.0.3530.0.  I have attached some screen shots of when Chrome becomes unresponsive.

The in_range flag I am referring to is in the Windows touch events.  A touch device will report it in the report descriptor see,
https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/supporting-usages-in-digitizer-report-descriptors

For apps the in_range flag is in the WM_TOUCH message see,
https://docs.microsoft.com/en-us/windows/desktop/wintouch/wm-touchdown

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/ns-winuser-tagtouchinput

Deleted: ChromeUnresponsive1.png 133 KB

	ChromeUnresponsive1.png 133 KB View Download

Deleted: ChromeUnresponsive2.png 78.5 KB

	ChromeUnresponsive2.png 78.5 KB View Download

Deleted: ChromeUnresponsive3.png 116 KB

	ChromeUnresponsive3.png 116 KB View Download

We definitely don't want to see Chrome crashing and you are right that we should fix this. But we need to first find what causes the crash. bokan@ do you know any method of getting some sort of logs in this case when the whole browser crashes? 

One thing for sure is that we never had a device that supports hovering touches. So I'm not sure how Chrome behaves with those events from the OS. So there might be places that we don't expect such a thing and that might lead to crash I believe.

In the meantime, we will be working on getting one of these smart boards.

I thought a dmp file may help you get started.  I reproduced the problem again then from Windows task manager I created a dump for the process that was not responding.  The file is too big to attach so I put it on google drive.

https://drive.google.com/file/d/1kSkoZ0aRjLnD1QrfqB_75Glibc78rVGJ/view?usp=sharing

Re: getting data from a crash, keithwildeatsmarttech@, does the crash show up in chrome://crashes? if so, you can paste the crash id here and we should be able to get some additional information.

Thanks for the dmp file, we can also use that to investigate but I'll need to get to a Windows box to do that.

When Chrome becomes unresponsive and the user has to tell Windows to close it, like in the screen shots I attached above, then there are no crashes in chrome://crashes.

Occasionally instead of becoming unresponsive Chrome just disappears, those show up in chrome://crashes.  I submitted one of those as issue ID=872312.  I am not sure if that was really a duplicate because I tried a canary build that supposedly had a fix for that in it but I was still able to get it to crash.  The other explanation is that there are multiple causes of these crashes and one cause was fixed but there are still others.

I had another question. What is your SMART BOARD model?

Hello,
I'd like to follow-up on this issue. What is the latest update? Were you able to replicate the issue on the 8000 series board?

We are in the process of installing our SMART board 800 to see whether we can reproduce  the issue there and debug it further. These are big boards and aren't easy to grab and install on at desk. We arranged time for people to come and install it but it takes some time. I don't know how we can expedite this more.

Thanks for the update.  If there is any more info that I can provide that would be helpful let me know.

Hi nzolghadr, were boards installed by chance?

keithwildeatsmarttech, even for  crbug.com/853681  we merged a fix into 70.0.3522.0 and you already tried .0.3524.0 and 70.0.3530.0 can you please additionally try current stable 70.0.3538.102, and run is as chrome.exe --enable-logging --v=1 and submit chrome_debug.log

Also, even Chrome is not crashing, but hanging, in recent version we also report some kind of hangs as crashes, so please 
make sure "Automatically send usage statistics and crash reports to Google" is enabled and try to reproduce on version 70.0.3538.102 and provide us pdf of chrome://crashes

+David who is the TAM for SmartTech

Hi

Daniel de Sao Jose (ddjose@) is the TAM for this account.

Yes. but we couldn't see any problem with that. However, the smart board that we have controls the mouse with the fingers. So can you confirm this for us. When you actually interact with the Chrome does it interact with it as if it is touch (like does Windows hide the mouse cursor) or does it just move the mouse cursor over that location and then simulate a click?

ddjose@ do you have any comment on this.

I tried the latest stable build, 70.0.3538.102, and I was able to reproduce it several times.  I enabled logging and attached the file.  I also created a pdf of the crashes page and attached it.  The "Automatically send usage statistics and crash reports to Google" setting is enabled.

I also tried the latest canary build, 72.0.3611.0 and I can still reproduce it there as well.

Let me know if you need me to do anything else.

Deleted: chrome_debug-70.0.3538.102.log 117 KB

chrome_debug-70.0.3538.102.log 117 KB View Download

Deleted: ChromeCrashes.pdf 97.7 KB

ChromeCrashes.pdf 97.7 KB Download

I forgot to mention that each time I reproduced it chrome became unresponsive and it does not seem to have generated a crash report.  As shown in the pdf the last crash that generated a report was in Aug.

I wonder if someone from QA team can take a look and see whether they can repro the issue and bisect it.

I was trying with Chrome 71 and one time it crashed instead of becoming unresponsive.  I clicked send now in chrome so hopefully it will show up.
Crash ID:3d22b170-87f5-418a-9e18-6c3d534e7283

The link given in a comment above now points to a build that will not reproduce the problem.  Here is the comment with a new link.

I have been using an 8000 series board, 6000 series will work too.
https://education.smarttech.com/en/products/6000-series

You will also need this version of drivers installed.  Uninstall any version of SMART Product drivers that you currently have on your machine before installing this one.
https://drive.google.com/open?id=1eaBLgLNyXjK1uv5Hi7JgqONDMXsGyCvw

I probably suffer from the same issue. I'm using Windows 10 IOT 1607 (14393.2670) using various Chrome/Chromium/Electron versions, all crashing in the same way: Application get's unresponsive.

I can 100% reproduce this by "touching like crazy" for about 3 minutes (i.e. hundreds of touch-events will be generated). It really seems to be dependent on the "count of touches performed" until it crashes, not on the time. Moreover, although I'm not 100% sure, it seems like it only happens if I touch with multiple fingers "at the same time". I.e. I tried to touch hundreds of times with only one finger and it didn't crash.

It is completely unrelated to the opened HTML/JS page, it even happens when done on the welcome/start page.

In case that it matters: I have a "eGalaxTouch EXC7200-7805v1.044"

I'm very willing to help debug this! Also I'm a C++ developer, which may be helpful here... BUT: I hesitate to build everything from scratch... so maybe you could assist me by providing me "binaries with additional debugging code" or the like and I help to reproduce and provide crash dumps, log files, etc.

I did a crashdump and analyzed it. Any interest of getting that one? (It's about 250MB). If yes, where should I upload it? From the dump, I was able to download the right symbols and thus got the callstack, which looks like this:


>	chrome.dll!std::_Hash<std::_Umap_traits<unsigned int,unsigned int,std::_Uhash_compare<unsigned int,base_hash::hash<unsigned int>,std::equal_to<unsigned int> >,std::allocator<std::pair<const unsigned int,unsigned int> >,0> >::_Insert<std::pair<const unsigned int,unsigned int> &,std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types<std::pair<const unsigned int,unsigned int> > > > >(std::pair<const unsigned int,unsigned int> & _Val, std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types<std::pair<const unsigned int,unsigned int> > > > _Pnode) Line 982	C++
 	chrome.dll!ui::SequentialIDGenerator::GetGeneratedID(unsigned int number) Line 45	C++
 	chrome.dll!views::HWNDMessageHandler::HandlePointerEventTypeTouch(unsigned int message, unsigned __int64 w_param, __int64 l_param) Line 2946	C++
 	chrome.dll!views::HWNDMessageHandler::OnPointerEvent(unsigned int message, unsigned __int64 w_param, __int64 l_param) Line 0	C++
 	chrome.dll!views::HWNDMessageHandler::HandlePointerMessage(unsigned int message, unsigned __int64 w_param, __int64 l_param, bool * handled) Line 1073	C++
 	chrome.dll!content::LegacyRenderWidgetHostHWND::OnPointer(unsigned int message, unsigned __int64 w_param, __int64 l_param) Line 385	C++
 	chrome.dll!content::LegacyRenderWidgetHostHWND::_ProcessWindowMessage(HWND__ * hWnd, unsigned int uMsg, unsigned __int64 wParam, __int64 lParam, __int64 & lResult, unsigned long dwMsgMapID) Line 0	C++
 	chrome.dll!content::LegacyRenderWidgetHostHWND::ProcessWindowMessage(HWND__ * hWnd, unsigned int uMsg, unsigned __int64 wParam, __int64 lParam, __int64 & lResult, unsigned long dwMsgMapID) Line 77	C++
 	chrome.dll!ATL::CWindowImplBaseT<ATL::CWindow,ATL::CWinTraits<1073741824,0> >::WindowProc(HWND__ * hWnd, unsigned int uMsg, unsigned __int64 wParam, __int64 lParam) Line 3548	C++
 	atlthunk.dll!00007ffdd0c51026()	Unknown
 	user32.dll!00007ffddd671c84()	Unknown
 	user32.dll!00007ffddd6715cc()	Unknown
 	chrome.dll!base::MessagePumpForUI::ProcessMessageHelper(const tagMSG & msg) Line 380	C++
 	chrome.dll!base::MessagePumpForUI::DoRunLoop() Line 175	C++
 	chrome.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 54	C++
 	chrome.dll!base::RunLoop::Run() Line 108	C++
 	chrome.dll!ChromeBrowserMainParts::MainMessageLoopRun(int * result_code) Line 1907	C++
 	chrome.dll!content::BrowserMainLoop::RunMainMessageLoopParts() Line 1000	C++
 	chrome.dll!content::BrowserMainRunnerImpl::Run() Line 166	C++
 	chrome.dll!content::BrowserMain(const content::MainFunctionParams & parameters) Line 47	C++
 	chrome.dll!content::RunBrowserProcessMain(const content::MainFunctionParams & main_function_params, content::ContentMainDelegate * delegate) Line 535	C++
 	chrome.dll!content::ContentMainRunnerImpl::Run(bool start_service_manager_only) Line 0	C++
 	chrome.dll!service_manager::Main(const service_manager::MainParams & params) Line 472	C++
 	chrome.dll!content::ContentMain(const content::ContentMainParams & params) Line 19	C++
 	chrome.dll!ChromeMain(HINSTANCE__ * instance, sandbox::SandboxInterfaceInfo * sandbox_info, __int64 exe_entry_point_ticks) Line 0	C++
 	chrome.exe!MainDllLoader::Launch(HINSTANCE__ * instance, base::TimeTicks exe_entry_point_ticks) Line 201	C++
 	chrome.exe!wWinMain(HINSTANCE__ * instance, HINSTANCE__ * prev, wchar_t *, int) Line 229	C++
 	chrome.exe!__scrt_common_main_seh() Line 283	C++
 	kernel32.dll!00007ffddfb98364()	Unknown
 	ntdll.dll!00007ffde004e851()	Unknown

The according code look like this, while execution was at "****>" at the time of having created the dump.

	template<class _Valty,
		class _Nodety>
		_Pairib _Insert(_Valty&& _Val, _Nodety _Pnode)
		{	// try to insert existing node with value _Val
		size_type _Bucket;
		_Unchecked_iterator _Where;

		_TRY_BEGIN
		_Bucket = _Hashval(_Traits::_Kfn(_Val));
		_Where = _End(_Bucket);
		while (_Where != _Begin(_Bucket))
			{
#pragma warning(push)
#pragma warning(disable: 4127)	// conditional expression is constant
****>			if (_Traitsobj(_Traits::_Kfn(_Val),
				_Traits::_Kfn(*--_Where)))
				;	// still too high in bucket list
			else if (_Multi
				|| (!_Traits::_Standard
					&& _Traitsobj(_Traits::_Kfn(*_Where),
						_Traits::_Kfn(_Val))))
				{	// found insertion point, back up to it
				++_Where;
				break;
				}
			else
				{	// discard new list element and return existing
				_Destroy_if_node(_Pnode);
				return (_Pairib(_Make_iter(_Where), false));
				}


Although this is not necessarily true, chances are that 'while (_Where != _Begin(_Bucket))' is never left. I briefly checked the first about 250 entries of _Where as I was hoping to see a cyclic list or the like, but I didn't see anything like that. But the collection seems to be rather long, as there were more than the checked 250:

-		std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<std::pair<const unsigned int,unsigned int> > >,std::_Iterator_base0>	{_Ptr=0x00000213528bddf0 {_Next=0x00000213528be190 {_Next=0x0000021352a3e3a0 {_Next=0x0000021352a3e440 {...} ...} ...} ...} }	std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<std::pair<const unsigned int,unsigned int> > >,std::_Iterator_base0>
		std::_Iterator_base0	{...}	std::_Iterator_base0
-		_Ptr	0x00000213528bddf0 {_Next=0x00000213528be190 {_Next=0x0000021352a3e3a0 {_Next=0x0000021352a3e440 {_Next=...} ...} ...} ...}	std::_List_node<std::pair<const unsigned int,unsigned int>,void *> *
-		_Next	0x00000213528be190 {_Next=0x0000021352a3e3a0 {_Next=0x0000021352a3e440 {_Next=0x0000021352a3eb20 {_Next=...} ...} ...} ...}	std::_List_node<std::pair<const unsigned int,unsigned int>,void *> *
-		_Next	0x0000021352a3e3a0 {_Next=0x0000021352a3e440 {_Next=0x0000021352a3eb20 {_Next=0x0000021350a12bd0 {_Next=...} ...} ...} ...}	std::_List_node<std::pair<const unsigned int,unsigned int>,void *> *

Thanks zulli73@ for the detailed analysis!

It would be helpful if you could upload the minidump to a GoogleDrive or equivalent service and post a link here.

Alternatively (and probably easier for everyone), if you can cause the crash in a real Chrome instance, go to chrome://crashes and post the CrashID here we can look up the dump and do analysis on our end.

I'm not a "Google Drive"-PowerUser but I hope this link works: https://drive.google.com/drive/folders/1bksrtjjOCiRZlDYV6gBfIV9JiEIQoTEQ?usp=sharing

Regarding the "chrome://crashes"-request: I'll try, but I'm not sure, whether this crash detection mechanism kicks in, as Chrome is just "busy" doing work... I'll report once I tried.

Thanks, I'll try to take a look at the dump when I get to a Windows box next week with WinDbg.

If Chrome is just locked-up rather than crashing, how did you get your dump? 

With the help of the „Windows Task Manager“: right clicking the process
opens the context menu which offers an “create dump“ or similar.

Small input: The application which is affected by this bug initially used Nativefier 7.6.7 which uses Electron 2.0.6, which uses Chrome 61.0.3163.100 (according to https://www.npmjs.com/package/electron-to-chromium). At that time, the crash did NOT occur.

Sometime later, I moved to electron 3.0.3 which uses Chrome 66.0.3359.181. With that version, the bug occurs.

Therefore, I think it's safe to say that the bug was introduced somewhere between 61.0.3163.100 and 66.0.3359.181. Note: As stated earlier, the issue is definitely not Electron related, as the issue also occurs with standard Chromium and Chrome.

Therefore, I'm now downgrading to Electron 2.0.6 to temporarily circumvent this issue on our side, as we need to release the software now.

 Issue 874498  has been merged into this issue.

We're experiencing what seems to be a similar problem. We're using a computer running Windows 10 with a touchscreen device that's listed as eGalaxTouch (similar to comment #30 above). Our app is using Electron and we found in testing that after about 2 hours of uptime we could reliably cause the app to freeze with rapid tapping.

While investigating we tried the same thing with just having Chrome open for 2 hours or so (open to Slack, in our test, although that might not matter) and similarly after about 2 hours we could cause the browser to freeze up after rapid tapping. Version 71.0.3578.98 at the moment.

@37, why was 874498 merged with this? This does not seem to be the same issue from what I'm reading here. Nothing in regards to how to reproduce this issue is even related.