How bad is a DumpWithoutCrashing for the user?

108 views
Skip to first unread message

Aaron Leventhal

unread,
Oct 20, 2023, 12:41:40 PM10/20/23
to Chromium-dev
We’ve had a spike of them in a11y code since 117 that I’m getting pinged about by a release manager. Obviously we want to address this specific issue as soon as we can. That said, the release manager and I aren't sure whether it should be considered a stable release blocker, because it's not an actual crash, and we aren’t sure about the impact on the user. My understanding is that the browser may become unresponsive as the crash data is collected and sent. 

Aaron

Mark Mentovai

unread,
Oct 20, 2023, 1:36:13 PM10/20/23
to aleve...@chromium.org, Chromium-dev
The process gets suspended while data is collected, and the time that collection takes is measured in milliseconds or tens of milliseconds (last I measured, which was a long time ago).

Doing it once, off of a critical path, usually isn’t noticeable. Doing a lot of it inside of a tight loop would be.

The upload itself happens in the background relative to all of this, and shouldn’t be noticeable. And uploads are rate-limited, so we probably wouldn’t send more than the first of these in an hour.

On Fri, Oct 20, 2023 at 12:41 PM Aaron Leventhal <aleve...@chromium.org> wrote:
We’ve had a spike of them in a11y code since 117 that I’m getting pinged about by a release manager. Obviously we want to address this specific issue as soon as we can. That said, the release manager and I aren't sure whether it should be considered a stable release blocker, because it's not an actual crash, and we aren’t sure about the impact on the user. My understanding is that the browser may become unresponsive as the crash data is collected and sent. 

Aaron

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAC2P9WkTLCEDb_97z9YR8CBsPdgiY%2BDJMd3M0aG3Rv0KP1ySpA%40mail.gmail.com.

Charlie Reis

unread,
Oct 20, 2023, 1:48:01 PM10/20/23
to ma...@chromium.org, aleve...@chromium.org, Chromium-dev
At least on Windows, there's usually a noticeable jank when it happens, so I'm guessing it's more on the order of hundreds of milliseconds on that platform.

Charlie

Srinivas Sista

unread,
Oct 20, 2023, 1:54:59 PM10/20/23
to cr...@chromium.org, ma...@chromium.org, aleve...@chromium.org, Chromium-dev
Usually, we would like to not allow dump with out crashes to stable channel. ( Not just from a user impact perspective). The crash data that we get is controlled, so if we are having dump with out crashes on the user machine, then some real crashes might not be uploaded due to the throttle. 

Also we have early channels to get the data for engineers to be able to fix the issue and not needing to get this on stable channel. 

So i think RBS does sound right, and we should fix before it goes to stable channel

Srinivas

Marshall Greenblatt

unread,
Oct 20, 2023, 2:25:12 PM10/20/23
to sriniv...@google.com, cr...@chromium.org, ma...@chromium.org, aleve...@chromium.org, Chromium-dev
On Fri, Oct 20, 2023 at 1:53 PM 'Srinivas Sista' via Chromium-dev <chromi...@chromium.org> wrote:
Usually, we would like to not allow dump with out crashes to stable channel. ( Not just from a user impact perspective).

How is DumpWithoutCrashing disabled for stable channel builds currently? I imagine that other Chromium-based applications would also like to disable DumpWithoutCrashing (while keeping real crashes), if possible.
 

Daniel Cheng

unread,
Oct 20, 2023, 2:45:14 PM10/20/23
to magree...@gmail.com, sriniv...@google.com, cr...@chromium.org, ma...@chromium.org, aleve...@chromium.org, Chromium-dev
It's not programatically disabled. It's more about fixing issues that are triggering DumpWithoutCrashing() (by fixing the underlying issue or not merging a CL to not dump).

Daniel

(resending from chromium.org, sorry)

Fergal Daly

unread,
Oct 22, 2023, 8:45:31 PM10/22/23
to dch...@chromium.org, magree...@gmail.com, sriniv...@google.com, cr...@chromium.org, ma...@chromium.org, aleve...@chromium.org, Chromium-dev
On Sat, 21 Oct 2023 at 03:44, Daniel Cheng <dch...@chromium.org> wrote:
It's not programatically disabled. It's more about fixing issues that are triggering DumpWithoutCrashing() (by fixing the underlying issue or not merging a CL to not dump).

Should it require explicit opt-in to DWoC in stable and be compiled off in stable by default? I've seen people cherry-pick changes to stop it reaching stable. It would be nice to cut that out,

F


 

Dana Jansens

unread,
Oct 23, 2023, 9:28:02 AM10/23/23
to ma...@chromium.org, aleve...@chromium.org, Chromium-dev
On Fri, Oct 20, 2023 at 1:35 PM Mark Mentovai <ma...@chromium.org> wrote:
The process gets suspended while data is collected, and the time that collection takes is measured in milliseconds or tens of milliseconds (last I measured, which was a long time ago).

Doing it once, off of a critical path, usually isn’t noticeable. Doing a lot of it inside of a tight loop would be.

The upload itself happens in the background relative to all of this, and shouldn’t be noticeable. And uploads are rate-limited, so we probably wouldn’t send more than the first of these in an hour.

AFAIK DwC calls throttle themselves, so they only will actually record something when called once every few minutes.
 

On Fri, Oct 20, 2023 at 12:41 PM Aaron Leventhal <aleve...@chromium.org> wrote:
We’ve had a spike of them in a11y code since 117 that I’m getting pinged about by a release manager. Obviously we want to address this specific issue as soon as we can. That said, the release manager and I aren't sure whether it should be considered a stable release blocker, because it's not an actual crash, and we aren’t sure about the impact on the user. My understanding is that the browser may become unresponsive as the crash data is collected and sent. 

Aaron

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAC2P9WkTLCEDb_97z9YR8CBsPdgiY%2BDJMd3M0aG3Rv0KP1ySpA%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Peter Boström

unread,
Oct 23, 2023, 10:35:24 AM10/23/23
to Dana Jansens, Mark Mentovai, aleve...@chromium.org, Chromium-dev
We changed the defaults so that this only happens once per location per day per process by default. If you're not dumping in short-lived process the user is unlikely to notice more than one jank (unless you do this in a critical loop since this takes a lock to check rate limiting, but surely you wouldn't think this would be a free function call).

The problem here is usually that if you DWC enough in pre-stable channels for release managers to notice and reach out to you then that often translates to a large amount of reports from stable and we end up flooding ourselves. Please comment these out on branch if that's the case and rethink your data-collection strategy if you still don't have enough information to deal with the reason why you put the DWC there in the first place. 

This should have better documentation, specifically around best practices and I'll try to make sure to do so when returning to work within a few weeks. Please ping me if this documentation is still lacking (or start writing it and let me know where it is).

Cheers
Peter

Reply all
Reply to author
Forward
0 new messages