Without any specific repro steps its difficult to triage this issue further.

Hence adding proper component for someone from the respective team to help in further triaging of this issue.

Hi there, I understand where you're coming from but it's quite difficult to reproduce. However there's definitely something not being handled gracefully on the IDB side of this as it's IDB for all sites across the browser going offline.

Keep in mind this is after running our arch for months with no such behaviour. I'm not able to provide a component as I work at company X that would consider that some kind of breach. Is there some profiling tools we can run that would maybe help us determine what's happening???

We have set timeouts on the callbacks (onsuccess etc) to log if they take too long to try and stab at it like that. But it's very difficult to determine as it only crashes out every few days on specific computers and once it does there's nothing to inspect till we restart the browser.

Something is hanging/deadlocking/bottlenecking inside IDB. I can feel it. But I can't determine how to inspect the issue since IDB isn't my code.

Cheers and thanks for your time.

Walter.

Is this affecting just one computer or multiple?

Does behavior vary across different versions of Chrome? The report indicates version 59 - do you see the behavior in the current version (61) or Beta/Canary (62/63) ?

Thanks very much for your response. It's happening on a few different browsers.

Version 59.0.3071.115 (Official Build) (32-bit)

This is the build we are presently supporting (and pretty much have to unless it is a version thing where we will push back)

We have also seen the issue on:

Version 61.0.3163.79 (Official Build) (64-bit)

Google Chrome 61.0.3163.91 (Official Build) (64-bit)

Revision 2f544949507dc5330b714cb017e3f584e791a1bf-refs/branch-heads/3163@{#1194}

Does chrome://indexeddb-internals show any unexpected details on one of the affected systems *before* things into a bad state? e.g. an unexpected number of pending transactions?

Another way to inspect what's happening is via tracing:
1. Go to chrome://tracing
2. Select Record (top left)
3. Expand Edit categories and select IndexedDB and leveldb
4. Click Record and let it run for a few seconds
5. Click Stop

You can zoom in and see if there is Indexed DB activity occurring in the browser process or a renderer process. 

Any further data here?

Hey there... we took a look at this and think we narrowed it down to a very edgey race condition that was causing a loop to keep opening a DB, failing, and opening again. I can actually find some code now and send it to you if you'd like to investigate because I think IDB crashing is likely not the graceful solution to such a condition. Thoughts?

Thank you for providing more feedback. Adding requester "jsbell@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Yes, a sample would be great.

Flagging as needs-feedback again. Interested in the code sample as well, or at least where that edge case is you're talking about :)

Closing as old, cannot reproduce. I'm guessing it's a known idb crasher, like the too-large databases, or the old problem with the semaphore file locking, which was fixed.