Closed Bug 1457603 Opened 7 years ago Closed 7 years ago

Intermittent gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application crashed [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc]

Categories

(Core :: Panning and Zooming, defect, P5)

Product:
Core
Component:
Panning and Zooming
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla64
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- disabled
firefox59 --- unaffected
firefox60 --- disabled
firefox61 --- disabled
firefox62 --- disabled
firefox63 - disabled
firefox64 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: botond)

References

Details

(Keywords: crash, intermittent-failure, topcrash)

Crash Data

Attachments

(1 file)

Bug 1457603 - Downgrade the diagnostic assert in InputBlockState::SetConfirmedTargetApzc() to a regular assert. r?kats
46 bytes, text/x-phabricator-request
kats
: review+
Details | Review
Filed by: ncsoregi [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=175979952&repo=mozilla-inbound https://queue.taskcluster.net/v1/task/GAcUpvrrRH2silrZHzH3rA/runs/0/artifacts/public/logs/live_backing.log [task 2018-04-27T16:06:48.426Z] 16:06:48 INFO - TEST-PASS | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | helper_drag_scroll.html | Scroll position strictly increased [task 2018-04-27T16:06:48.426Z] 16:06:48 INFO - TEST-PASS | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | helper_drag_scroll.html | Scroll position strictly increased [task 2018-04-27T16:06:48.427Z] 16:06:48 INFO - TEST-PASS | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | helper_drag_scroll.html | Scroll position strictly increased [task 2018-04-27T16:06:48.428Z] 16:06:48 INFO - TEST-PASS | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | helper_drag_scroll.html | Scroll position strictly increased [task 2018-04-27T16:06:48.429Z] 16:06:48 INFO - TEST-PASS | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | helper_drag_scroll.html | Scroll position strictly increased [task 2018-04-27T16:06:48.430Z] 16:06:48 INFO - Buffered messages finished [task 2018-04-27T16:06:48.431Z] 16:06:48 ERROR - TEST-UNEXPECTED-FAIL | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application terminated with exit code 11 [task 2018-04-27T16:06:48.432Z] 16:06:48 INFO - runtests.py | Application ran for: 0:00:30.189345 [task 2018-04-27T16:06:48.432Z] 16:06:48 INFO - zombiecheck | Reading PID log: /tmp/tmpdo4D4kpidlog [task 2018-04-27T16:06:48.433Z] 16:06:48 INFO - ==> process 5846 launched child process 5869 [task 2018-04-27T16:06:48.434Z] 16:06:48 INFO - ==> process 5846 launched child process 5905 [task 2018-04-27T16:06:48.434Z] 16:06:48 INFO - ==> process 5846 launched child process 5961 [task 2018-04-27T16:06:48.435Z] 16:06:48 INFO - zombiecheck | Checking for orphan process with PID: 5905 [task 2018-04-27T16:06:48.436Z] 16:06:48 INFO - zombiecheck | Checking for orphan process with PID: 5869 [task 2018-04-27T16:06:48.436Z] 16:06:48 INFO - zombiecheck | Checking for orphan process with PID: 5961 [task 2018-04-27T16:06:48.437Z] 16:06:48 INFO - mozcrash Downloading symbols from: https://queue.taskcluster.net/v1/task/cG1q7flySR67aQPJRtTpNA/artifacts/public/build/target.crashreporter-symbols.zip [task 2018-04-27T16:06:54.991Z] 16:06:54 INFO - mozcrash Copy/paste: /usr/local/bin/linux64-minidump_stackwalk /tmp/tmpREBFSy.mozrunner/minidumps/1dfc8dd4-121d-fe20-203f-473fc9b3b50f.dmp /tmp/tmpjYMnaI [task 2018-04-27T16:07:03.664Z] 16:07:03 INFO - mozcrash Saved minidump as /builds/worker/workspace/build/blobber_upload_dir/1dfc8dd4-121d-fe20-203f-473fc9b3b50f.dmp [task 2018-04-27T16:07:03.664Z] 16:07:03 INFO - mozcrash Saved app info as /builds/worker/workspace/build/blobber_upload_dir/1dfc8dd4-121d-fe20-203f-473fc9b3b50f.extra [task 2018-04-27T16:07:03.831Z] 16:07:03 INFO - PROCESS-CRASH | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | application crashed [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc]
Blocks: 1437694
I tested the URLs mentioned in bug 1455860 comment 3. However, they all fall into one of the following categories: - Requires a login, so that I don't actually see the same page that the who experienced the crash saw - I didn't see a subframe scrollbar (which is required to trigger the crash) on the page - Dragging the subframe scrollbar(s) didn't trigger the crash for me So, we're back to needing someone who is still experiencing this crash provide STR.
Setting Fx60 status to disabled since this will go away when 60 goes to release (on 60, the assert is only enabled on DevEdition builds).
status-firefox59: --- → unaffected
status-firefox60: --- → disabled
status-firefox61: --- → affected
status-firefox-esr52: --- → unaffected
status-firefox-esr60: --- → disabled
See Also: → 1460123
Crash whilst I was switching sheet in googlesheets.
(In reply to Ludovic Hirlimann [:Usul] from comment #7) > Crash whilst I was switching sheet in googlesheets. Can you trigger the crash reliably? If so, could you provide some STR, and if it's specific to a particular spreadsheet, its URL?
Flags: needinfo?(ludovic)
(In reply to Botond Ballo [:botond] from comment #8) > (In reply to Ludovic Hirlimann [:Usul] from comment #7) > > Crash whilst I was switching sheet in googlesheets. > > Can you trigger the crash reliably? If so, could you provide some STR, and > if it's specific to a particular spreadsheet, its URL? NO :( I can't.
Flags: needinfo?(ludovic)
The crash rate here has been trending slightly down over time, which is encouraging, but there still is still a fairly steady stream of crashes. I continue to be interested in STR for reproducing remaining instances.
Adding 63 as affected. In 7 days on 63 nightly I show 168 crashes/227 installs. Currently #8 top browser crash on nightly. I don't see any comments, and there is no obvious pattern to the urls on any of the platforms.
status-firefox63: --- → affected
Keywords: topcrash
We may want to track this for 63 since it's a topcrash on Nightly.
status-firefox62: affected → fix-optional
tracking-firefox63: --- → ?
Note that, as explained in bug 1447131 comment 34, the "crashes" here are caused by the firing of a nightly-only diagnostic assert (at the time it was nightly + early beta, now it's nightly only). That means that when 63 merges to beta and later release, the crashes will no longer happen on those channels. If we decide to track this anyways (presumably on the basis that the crash volume is higher than what we want Nightly users to put up with) and no one experiencing such a crash provides STR in the 63 timeframe, we may have no option but to revert the diagnostic assert, or restrict it to debug builds.
In case this is useful: I just got this crash (once) in http://airbnb.io/enzyme/docs/api/mount.html, while scrolling the left pane using the mouse on the scrollbar. My crash is: https://crash-stats.mozilla.com/report/index/e8583764-0cc4-4774-8785-3eaa80180713#tab-details
Unfortunately, I wasn't able to trigger a crash on that page (and sounds like it was a one-off for you as well).
This happened to me today on the new gmail interface, while scrolling down the inbox. (but again, this was a one-off).
In the new gmail interface, the inbox is in a scrollable <div>, just like the left pane in the airbnb website above.
This happened a second time. Given I use gmail a lot, this will likely happen more now, and then be also more painful.
I switched to the new Gmail interface in the hope that I will be able to reproduce this too. No luck so far. Do you have the Preview Pane enabled?
I managed to get a pretty reliable STR for this crash on latest Nightly. Takes a few time to actually trigger it but it works for me every time: 1. Open this link: https://pontoon.mozilla.org/he/amo/all-resources/?status=missing&string=134038 2. Keep scrolling down until you get to the last string for translation (stay up-to-date with news ...) and click it 3. Drag the scroller to the top, and then to the right (in a way that the scroller will appear at the bottom) and release. 4. Repeat step 3 a few times, usually 3-4 times to trigger the crash (note that Nightly won't (most of the time) crash entirely, but a crash signature will still appear at about:crashes) 5. In order to retrigger the crash, reload the page and do the whole thing again. A few crash signatures that were reproduced with said STR: https://crash-stats.mozilla.com/report/index/bf1956e4-61c6-43b2-bdfd-8c1c30180903 https://crash-stats.mozilla.com/report/index/e3ad7318-c3cd-4bce-861c-9be740180903 https://crash-stats.mozilla.com/report/index/4fcd80e7-f939-4b81-8a7f-e2e790180903 https://crash-stats.mozilla.com/report/index/05508d27-e4f2-4f48-917a-0ecd40180903 https://crash-stats.mozilla.com/report/index/e2d5b19e-9d2c-4d43-8bca-01f3d0180903 https://crash-stats.mozilla.com/report/index/c675f45f-a111-4140-950e-d5a8d0180903 https://crash-stats.mozilla.com/report/index/3fedea78-f494-4802-9f23-6cf760180903 If you need a screencast let me know.
Has STR: --- → yes
(In reply to Botond Ballo [:botond] from comment #22) > I switched to the new Gmail interface in the hope that I will be able to > reproduce this too. No luck so far. > > Do you have the Preview Pane enabled? I don't think I have the Preview Pane enabled. Note this happens when I read a (long) mail, not when a write a mail, and when I scroll it using the scroller. As Itiel says, the key might be in how I scroll up/down, maybe I move the mouse a lot to the right as well. I'll take care whether I'm doing this. This happened to me recently in the devtools as well. Similar STR, I think I was using the Canvas tool.
(In reply to Itiel from comment #23) > I managed to get a pretty reliable STR for this crash on latest Nightly. > Takes a few time to actually trigger it but it works for me every time: I tried this on both Linux and Windows, but was unable to reproduce the crash. > If you need a screencast let me know. If you don't mind creating one, it might be helpful in that it might show me something I was doing differently from you. Thanks!
(In reply to Julien Wajsberg [:julienw] from comment #25) > https://crash-stats.mozilla.com/report/index/40808087-ff75-4e41-804e- > e29a40180904 happened in phabricator. (similar STR) I assume by "similar STR" you mean you were dragging a scrollbar (which is not surprising, all crashes on this line involve scrollbar dragging), but can you say which view you were looking at in Phabricator, and which scrollable element were you scrolling?
(In reply to Botond Ballo [:botond] from comment #26) > If you don't mind creating one, it might be helpful in that it might show me > something I was doing differently from you. Thanks! I was about to do just that, but now I see that for some reason the STR mentioned in comment 23 does not trigger the crash, even if I try it multiple times. But eventually I do get a crash if I play with the scroller too much.
Not sure at this point how to consistently reproduce this crash. I'm willing to provide remote access to my machine so you'd debug it from here.
(In reply to Botond Ballo [:botond] from comment #27) > (In reply to Julien Wajsberg [:julienw] from comment #25) > > https://crash-stats.mozilla.com/report/index/40808087-ff75-4e41-804e- > > e29a40180904 happened in phabricator. (similar STR) > > I assume by "similar STR" you mean you were dragging a scrollbar (which is > not surprising, all crashes on this line involve scrollbar dragging), but > can you say which view you were looking at in Phabricator, and which > scrollable element were you scrolling? Oh yeah I should have added this information. I was looking at this URL: https://phabricator.services.mozilla.com/D3618 And I was using the "main" scrollbar at the right.
So at this point I'll share some more information about my environment, because that may be the difference that triggers the issue. I'm on Debian Stable. Which means gtk3 is version 3.22.11. My Firefox is using the french locale. Linux kernel is 4.17.8.
(In reply to Julien Wajsberg [:julienw] from comment #30) > (In reply to Botond Ballo [:botond] from comment #27) > > (In reply to Julien Wajsberg [:julienw] from comment #25) > > > https://crash-stats.mozilla.com/report/index/40808087-ff75-4e41-804e- > > > e29a40180904 happened in phabricator. (similar STR) > > > > I assume by "similar STR" you mean you were dragging a scrollbar (which is > > not surprising, all crashes on this line involve scrollbar dragging), but > > can you say which view you were looking at in Phabricator, and which > > scrollable element were you scrolling? > > Oh yeah I should have added this information. > > I was looking at this URL: https://phabricator.services.mozilla.com/D3618 > And I was using the "main" scrollbar at the right. Unfortunately, I haven't been able to reproduce this one either. (In reply to Julien Wajsberg [:julienw] from comment #31) > So at this point I'll share some more information about my environment, > because that may be the difference that triggers the issue. > > I'm on Debian Stable. Which means gtk3 is version 3.22.11. My Firefox is > using the french locale. > Linux kernel is 4.17.8. Do you use GNOME as your desktop environment? (I'm using Debian stable too, but with KDE. Wonder if that makes a difference...)
Crash Signature: [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc] → [@ mozilla::layers::InputBlockState::SetConfirmedTargetApzc] [@ <name omitted> | mozilla::layers::InputQueue::ConfirmDragBlock ]
This crash happens very often when using the responsive design mode of Firefox and resizing the responsive window since a few days.
Sorry for the delay, I was away. > Do you use GNOME as your desktop environment? (I'm using Debian stable too, but with KDE. Wonder if that makes a difference...) Yes I use Gnome.
(In reply to Sören Hentzschel from comment #34) > This crash happens very often when using the responsive design mode of > Firefox and resizing the responsive window since a few days. What platform?
(In reply to Julien Wajsberg [:julienw] from comment #35) > Sorry for the delay, I was away. > > > Do you use GNOME as your desktop environment? (I'm using Debian stable too, but with KDE. Wonder if that makes a difference...) > > Yes I use Gnome. I borrowed a colleague's machine running Gnome, and re-tested the STR in this bug, but still no luck.
> I borrowed a colleague's machine running Gnome, and re-tested the STR in this bug, but still no luck. Yes, it's not frequent even for me. What could be a good path forward? Running Firefox inside gdb so that I can inspect stuff if this crashes?
(In reply to Botond Ballo [:botond] from comment #36) > (In reply to Sören Hentzschel from comment #34) > > This crash happens very often when using the responsive design mode of > > Firefox and resizing the responsive window since a few days. > > What platform? OS X 10.11.6. It doesn't happen every time but today it happened more than ten times and happened a few days ago for the first time (I use the responsive design mode every day). To give you more precise STR: 1. open a website and use the responsive design mode 2. change the size of the responsive window 3. scroll on the page with the mouse wheel 4. sometimes it happens that scrolling with the mouse wheel no longer works 5. if that's the case try to drag the scrollbar => that's the moment where Firefox crashes But you can prevent the crash: In step 4 if the scrolling doesn't work: just reload the website. After reloading scrolling works again and there is no crash. That's one of my crash reports: https://crash-stats.mozilla.com/report/index/4ce2e674-1ab8-4b84-8f3f-f63f80180918
(In reply to Sören Hentzschel (not available from 2018/09/20 until 2018/09/27) from comment #39) > To give you more precise STR: > > 1. open a website and use the responsive design mode > 2. change the size of the responsive window > 3. scroll on the page with the mouse wheel > 4. sometimes it happens that scrolling with the mouse wheel no longer works > 5. if that's the case try to drag the scrollbar => that's the moment where > Firefox crashes I haven't been able to trigger (4) so far. Is there a specific website you were viewing whe it happened for you?
(In reply to Julien Wajsberg [:julienw] from comment #38) > Yes, it's not frequent even for me. What could be a good path forward? > Running Firefox inside gdb so that I can inspect stuff if this crashes? I'm not very optimistic about our chances of debugging this if we don't have reliable STR, unless perhaps we were able to get an rr / pernosco recording. If the crash is annoying to the point where it is affecting usability, we could consider downgrading it from a diagnostic assert to a regular (debug-build-only) assert. We made it a diagnostic assert because when it's hit it indicates an underlying compositor hit testing problem that we'd like to discover and fix, but we are able to recover from the situation (as we currently do in Beta/Release builds).
> I haven't been able to trigger (4) so far. Is there a specific website you were viewing whe it happened for you? I tested on a different system with macOS Mojave and was able to reproduce on this (in progress) website: http://web10096.web4.mynet.at/de Please note that it's possible that you have to repeat the steps 2 and 3 a few times until step 4 happens. Crash report of this system: https://crash-stats.mozilla.com/report/index/55c2ce26-4155-47db-9211-72bf00180918
(In reply to Sören Hentzschel (not available from 2018/09/20 until 2018/09/27) from comment #42) > > I haven't been able to trigger (4) so far. Is there a specific website you were viewing whe it happened for you? > > I tested on a different system with macOS Mojave and was able to reproduce > on this (in progress) website: > http://web10096.web4.mynet.at/de > > Please note that it's possible that you have to repeat the steps 2 and 3 a > few times until step 4 happens. Hmm, so I can trigger step (4) very often on that website, but then dragging the scrollbar works fine. That said, step (4) itself seems like a bug. It may be worth investigating, as it could potentially shed light on the scrollbar drag issue.
Is there anything I can do to help find the cause? > If the crash is annoying to the point where it is affecting usability For me as a web developer if affects the usability very much becaue I have to do my job and Firefox crashes every time when I make adjustments for different screen sizes.
(In reply to Sören Hentzschel (not available from 2018/09/20 until 2018/09/27) from comment #44) > For me as a web developer if affects the usability very much becaue I have > to do my job and Firefox crashes every time when I make adjustments for > different screen sizes. Have you considered using Firefox Developer Edition for your testing? Diagnostic asserts like this do not cause crashes in Developer Edition.
This is the top non-hang crash on Linux for the 9-19 Nightly build, with 7 crashes across 5 installs.
(In reply to Andrew McCreight [:mccr8] from comment #46) > This is the top non-hang crash on Linux for the 9-19 Nightly build, with 7 > crashes across 5 installs. Also on OSX for those Nightly builds.
and Windows...
Based on the comments above, I think we have gotten to the point where this diagnostic assert is doing more harm (by crashing the browser on Nightly users) than good (by identifying compositor hit testing bugs). It has been very difficult to find reliable STR for the diagnostic assert. We have a potential lead in comment 43, but it's not clear if the issue that I can reproduce is related to the diagnostic assert, and I also don't have the bandwidth to investigate it in the timeframe of the next few days. Therefore, I propose downgrading this diagnostic assert to a regular assert for the time being. We can still investigate the STR in comment 43 when we have time, and if it leads to fixing a compositor hit testing bug, we can try re-enabling this diagnostic assert to see if the bug that was fixed was the cause of the high volume of crashes. There is also an ongoing discussion on dev-platform about creating a mechanism to submit "crash reports" without actually crashing the browser [1]. If such a mechanism gets implemented, I think this assertion would be a good candidate for using it. [1] https://groups.google.com/d/msg/mozilla.dev.platform/Z5ikfQMTJUA/sV4lIMOCCQAJ
Assignee: nobody → botond
FWIW I didn't crash for 2 weeks (incl 1 week PTOs where I didn't use the computer at all). So maybe my specific case has been fixed since then...
As explained in the bug, it has been difficult ot find reliable STR for the diagnostic assert, and it has been impacting the stability and usability of Nightly builds.
Comment on attachment 9011016 [details] Bug 1457603 - Downgrade the diagnostic assert in InputBlockState::SetConfirmedTargetApzc() to a regular assert. r?kats Kartikaya Gupta (email:kats@mozilla.com) (parental leave) has approved the revision.
Attachment #9011016 - Flags: review+
Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4d1b24ff04cd Downgrade the diagnostic assert in InputBlockState::SetConfirmedTargetApzc() to a regular assert. r=kats
https://hg.mozilla.org/mozilla-central/rev/4d1b24ff04cd
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox64: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Want to backport this to Beta for DevEdition users?
Flags: needinfo?(botond)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #55) > Want to backport this to Beta for DevEdition users? We limited the assertion to the Nightly channel only back in bug 1455860, so there should be no need.
Flags: needinfo?(botond)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: