1633153 - Crash in [@ gdk_event_set_source_device]

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect, P3)

Description

[Alexander Sergeyev]

Attachment: firefox75-stack-trace.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Steps to reproduce are hard to distill and firefox does not crash constantly (currently, 3 times with similar stack traces within 2 weeks). Doesn't look that it's related to the viewed content, more likely GUI actions (opening a new tab). Also, there is a hint of race conditions, since all crashes happened with a heavy cpu load in the background. A stack trace is attached.

Actual results:

Firefox is terminated due to a segfault.

Expected results:

Firefox shouldn't have crashed.

Comment 1

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

Would you mind attaching a video of the issue so I can try to replicate on my end? please send us a link with the crash report. You can find more info about crash reports here: https://support.mozilla.org/en-US/kb/mozillacrashreporter

Please test if the issue occurs to you in safe mode (add-ons disabled). Here is a link that can help you do that:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

If the issue persists, also test it using a fresh profile, you can find the steps to do that below:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Also, try this on the latest version of nightly. You can download it from here: https://nightly.mozilla.org/

Thanks for the report.

Best regards, Clara.

Comment 2

[Alexander Sergeyev]

Hi, Clara,

Would you mind attaching a video of the issue so I can try to replicate on my end?

I'm afraid it's too rare for this strategy to be applicable. At rate of single crash per 3-4 days, I would need to keep screen recording constantly on and configure it to keep only last N minutes of the recording on disk (the disk has its limits). And there are no guarantees that these N minutes will be helpful (I'm not doing anything special when the browser crashes).

Comment 3

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (non,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 4

[Clara Guerrero ( Need Info Brindusa Tot Please)]

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Would be useful to have a log from terminal. Can you run firefox from command line and check if there's any error message like:

Gdk-CRITICAL **: 20:08:35.754: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed

Comment 6

[Alexander Sergeyev]

I can't reliably reproduce crashes, but I didn't close the terminal window since the last crash, so there are some logs.
No such messages there (neither gdk nor any criticals). A lot of javascript errors and the last lines are:

Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Segmentation fault (core dumped)

Also, I've updated to Firefox-76.0.1 and gtk+-3.24.20, the problem is still present.

Comment 7

[Alexander Sergeyev]

I think I'm starting to see a pattern. Looks like these crashes happen only when I relatively quickly open a new tab via Ctrl+T and then switch from the address bar to the search bar via Tab -- I have "Add search bar in toolbar" setting enabled. Not every time though.

Comment 8

[Alexander Sergeyev]

Attachment: firefix-81.0.2-stacktrace.txt

Comment 9

[Alexander Sergeyev]

Firefox 81.0.2 is still affected. Also, it looks like there is an additional bug report regarding a similar problem [1].

The problem seems to be present on xcfe terminal application as well [2], which either means the bug is in gtk libraries or there are similar bugs regarding gtk api usage.

Firefox crashed in gdk_event_set_source_device() inside GDK_IS_DEVICE (device) [3] as before. The device pointer argument points to corrupted data, while there seem to be no issues with the event pointer data.

>> frame
#3  0x000070ea4d1a0cfd in gdk_event_set_source_device (event=0x70ea0b34c380, device=0x70ea139fd0e0) at /var/tmp/portage/x11-libs/gtk+-3.24.22/work/gtk+-3.24.22/gdk/gdkevents.c:1770
1770    in /var/tmp/portage/x11-libs/gtk+-3.24.22/work/gtk+-3.24.22/gdk/gdkevents.c
>> p *device
$9 = {
  parent_instance = {
    g_type_instance = {
      g_class = <error reading variable: Cannot access memory at address 0xe5e5e5e5e5e5e5e5>
    },
    ref_count = 3857049061,
    qdata = 0xe5e5e5e5e5e5e5e5
  },
  name = 0xe5e5e5e5e5e5e5e5 <error: Cannot access memory at address 0xe5e5e5e5e5e5e5e5>,
  source = 3857049061,
  mode = (GDK_MODE_SCREEN | unknown: 3857049060),
  has_cursor = -437918235,
  num_axes = -437918235,
  axes = 0xe5e5e5e5e5e5e5e5,
  num_keys = -437918235,
  keys = 0xe5e5e5e5e5e5e5e5
}

Exactly the same problem is described here [4].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1670096
[2] https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/56
[3] https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/gdkevents.c#L1770
[4] https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/56#note_14561

Comment 10

[Gian-Carlo Pascutto [:gcp]]

This is still showing up (albeit rare) in crash data and I don't like the look of the stacks.

Comment 11

[BugBot [:suhaib / :marco]]

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit BugBot documentation.

Comment 12

[BugBot [:suhaib / :marco]]

Closing because no crashes reported for 12 weeks.