Closed Bug 1737810 Opened 4 years ago Closed 3 years ago

Crash after snap update: "adding native font failed: file=/usr/share/fonts/truetype/[...].ttf" (Workaround: `snap set core experimental.refresh-app-awareness=true`)

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 94
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr91 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix

People

(Reporter: achats+bugzilla, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, Whiteboard: qa-not-actionable)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/0eea0c3c-b781-4d43-a20c-d05ef0211026

MOZ_CRASH Reason: adding native font failed: file=/usr/share/fonts/truetype/ubuntu/Ubuntu-R.ttf

Top 2 frames of crashing thread:

0 libxul.so libxul.so@0x5cd4f5e 
1 libxul.so libxul.so@0x50373ac

This crash is occurring frequently (at least once a day) on all machines since Ubuntu 21.10 with Firefox's Snap.

The same crash has also been happening in the stable version.

Whiteboard: qa-not-actionable

I too have just started suffering from this problem, after having switched from using the deb version to the snap version. Given this theory that it's something to do with snap, I've spotted this suspect message in my kern.log - I guess 140160 was the Firefox process?

kernel: [166766.739545] audit: type=1400 audit(1635346324.148:806): apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/proc/140160/environ" pid=159703 comm="WRWorker#0" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

The only other failure message I can see is this, which may be related to Project Fission which was occasionally hanging Firefox when attempt view videos:

[153500.825274] audit: type=1107 audit(1635332402.253:800): pid=1040 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/RealtimeKit1" interface="org.freedesktop.RealtimeKit1" member="MakeThreadRealtimeWithPID" mask="send" name="org.freedesktop.RealtimeKit1" pid=139889 label="snap.firefox.firefox" peer_pid=1357 peer_label="unconfined"

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: General → Layout: Text and Fonts
Product: Firefox → Core

Moving this to Graphics, as the failure is happening inside WebRender at painting time (it's not a Layout issue).

Component: Layout: Text and Fonts → Graphics: WebRender
Blocks: snap
Keywords: crash
Summary: Crash in [@ libxul.so@0x5cd4f5e | libxul.so@0x50373ac] → Snap: Crash in [@ libxul.so@0x5cd4f5e | libxul.so@0x50373ac]

New ones on 95beta:

I am not sure it's a coincidence, but the crashes seem to occur more frequently in the first seconds when using Firefox right after the whole computer hasn't been in use for 20-30min (but not idle).
It doesn't seem to happen when Firefox is actively in use.

status-firefox94: --- → affected
status-firefox95: --- → affected
Summary: Snap: Crash in [@ libxul.so@0x5cd4f5e | libxul.so@0x50373ac] → Snap: Crash: "adding native font failed: file=/usr/share/fonts/truetype/[...].ttf"
Severity: -- → S3
Flags: needinfo?(aosmond)
Depends on: 1740258

(Will May from comment #3)

kernel: [166766.739545] audit: type=1400 audit(1635346324.148:806): apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/proc/140160/environ" pid=159703 comm="WRWorker#0" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

Does Snap Firefox use the wrong path or should it have access to /usr/share/fonts/truetype/[...].ttf?

Flags: needinfo?(olivier)

Does anyone have a link to crashes on Nightly from the last few days?

There is no Nightly Snap, only Beta+Stable+ESR.

Interesting: "adding native font failed but opened file=/usr/share/fonts/truetype/fonts-japanese-gothic.ttf" so we can access the fonts but are failing to load them for some other reason.

Depends on: 1741638

Thanks, I've put up bug 1741638 which should give us more information when it lands.

Adding some more Linux crash signatures with "adding native font failed":
https://crash-stats.mozilla.org/search/?moz_crash_reason=~adding%20native%20font%20failed&product=Firefox&platform=Linux&date=%3E%3D2021-11-11T20%3A57%3A00.000Z&date=%3C2021-11-18T20%3A57%3A00.000Z&_facets=signature&_facets=moz_crash_reason&_facets=version&_facets=distribution_id&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-moz_crash_reason

Crash Signature: [@ libxul.so@0x5cd4f5e | libxul.so@0x50373ac] → [@ libxul.so@0x5cd4f5e | libxul.so@0x50373ac] [@ libxul.so@0x5cf579e | libxul.so@0x5046d1c ] [@ libxul.so@0x5ca281e | libxul.so@0x4ffe0ac ] [@ <rayon_core::job::HeapJob<BODY> as rayon_core::job::Job>::execute ] [@ libxul.so@0x5fed53e | libxul.so@0x535…

Hmm... 　It happens not only on my cases but also...
... but only on linux ...

and on some unknown OS ...

(In reply to Darkspirit from comment #7)

Does Snap Firefox use the wrong path or should it have access to /usr/share/fonts/truetype/[...].ttf?

It already does, the firefox snap's apparmor profile (/var/lib/snapd/apparmor/profiles/snap.firefox.firefox) includes <abstractions/fonts>, which grants read access to /usr/share/fonts/{,**}.

Flags: needinfo?(olivier)
Blocks: wr-stability
No longer blocks: snap
Crash Signature: libxul.so@0x5352079 | libxul.so@0x5351f9b | libxul.so@0x5590c2a | libxul.so@0x77d4726 | libxul.so@0x5110466 | libxul.so@0x87c6aaf | libxul.so@0x87eb42f | firefox@0x13c55 ] → libxul.so@0x5352079 | libxul.so@0x5351f9b | libxul.so@0x5590c2a | libxul.so@0x77d4726 | libxul.so@0x5110466 | libxul.so@0x87c6aaf | libxul.so@0x87eb42f | firefox@0x13c55 ] [@ libxul.so@0x67f2881 | libxul.so@0x4234aa6 | libxul.so@0x42346d8 | libxul.so@0x…
Summary: Snap: Crash: "adding native font failed: file=/usr/share/fonts/truetype/[...].ttf" → Crash: "adding native font failed: file=/usr/share/fonts/truetype/[...].ttf"
Crash Signature: __pthread_mutex_unlock ] → __pthread_mutex_unlock ] [@ @0x7f62d93c6dde ] [@ libxul.so@0x5fed2be | libxul.so@0x5353509 | libxul.so@0x535342b | libxul.so@0x55923ba | libxul.so@0x77d2666 | libxul.so@0x5110376 | libxul.so@0x87c4aaf | libxul.so@0x87e942f | firefox@0x13c55 ] [@ libxu…

Err: 2 seems to be Unknown_File_Format

So this seems to be happening for various fonts; skimming through the reports, I see at least these:

/usr/share/fonts/truetype/fonts-japanese-gothic.ttf
/usr/share/fonts/truetype/takao-gothic/TakaoGothic.ttf
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc
/usr/share/fonts/truetype/ubuntu/Ubuntu-R.ttf
/usr/share/fonts/truetype/croscore/Cousine-Regular.ttf

It's hard to imagine that there's really something wrong with all these fonts (which are commonly-used fonts that normally work fine). Is it possible that the snap environment somehow intercepts file accesses as part of its sandboxing/security, and is doing something unreliable such that sometimes when freetype tries to read the file, it gets broken data?

I'm seeing peaks of 200+ crashes per day on this, which given the Linux user population, and the fact that it appears Snap specific, which has even less users (for now), means that it is rather common. And given that Ubuntu is moving to Snap as default, this is really a timebomb. Raising to S2.

Not clear where the bug sits though, Firefox or Snap. Given that we don't see this bug outside Snap...

Severity: S3 → S2
Status: UNCONFIRMED → NEW
Ever confirmed: true

This happened to me yesterday, and the crash report is here: https://crash-stats.mozilla.org/report/index/bc5c974f-97bf-4ac1-979c-64aec0211123

I noticed that this coincided with a snap update. My /snap/firefox/current was updated from 701 to 731 at 20:17 (AEDT), and then this crash happened at 20:24. I suspect there is a good chance the snap update could have been a cause of this crash.

In light of this last comment, I'm suspecting this might indeed be caused by the firefox snap (or the gnome platform snap which it depends on) being refreshed while it's running. There is work ongoing to prevent this, and an experimental feature already allows this, but it's not enabled by default, see https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736 for details.

To everyone affected, next time you hit a similar crash, can you share the output of snap changes to confirm that the crash happened shortly after either the firefox snap or the gnome-3-38-2004 snap were updated?

And as a workaround until this is properly fixed in snapd, I strongly suggest turning on the experimental feature:

snap set core experimental.refresh-app-awareness=true

How often are snap updates likely to be happening? It seems like some people (see raycy.jp's comment 13, for example) find themselves hitting this very frequently -- could there be so many updates being applied in quick succession?

Indeed that doesn't add up. Snap updates follow upstream releases (in the beta channel there might be additional updates when build dependencies are being bumped).

raycy.jp's font crashes are bug 1720573.

Blocks: snap
Summary: Crash: "adding native font failed: file=/usr/share/fonts/truetype/[...].ttf" → Crash after snap update: "adding native font failed: file=/usr/share/fonts/truetype/[...].ttf" (Workaround: `snap set core experimental.refresh-app-awareness=true`)
> snap changes
ID   Status  Spawn               Ready               Summary
250  Done    today at 17:01 CET  today at 17:01 CET  Auto-refresh snap "firefox"

-> Crashed 3 hours after: https://crash-stats.mozilla.org/report/index/bp-dd98cba8-1320-43d8-92e2-3ffc30211124

> snap changes
ID   Status  Spawn               Ready               Summary
344  Done    today at 14:17 CET  today at 14:17 CET  Auto-refresh snap "firefox"

-> Crashed 6 hours later.

Thanks! Can you share the output of snap tasks 250 and snap tasks 344?

Flags: needinfo?(achats+bugzilla)

(In reply to Olivier Tilloy from comment #44)

Thanks! Can you share the output of snap tasks 250 and snap tasks 344?

snap tasks 250
Status  Spawn                   Ready                   Summary
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Ensure prerequisites for "firefox" are available
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Download snap "firefox" (737) from channel "latest/beta"
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Fetch and check assertions for snap "firefox" (737)
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Mount snap "firefox" (737)
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Run pre-refresh hook of "firefox" snap if present
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Stop snap "firefox" services
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Remove aliases for snap "firefox"
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Make current revision for snap "firefox" unavailable
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Copy snap "firefox" data
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Setup snap "firefox" (737) security profiles
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Make snap "firefox" (737) available to the system
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Automatically connect eligible plugs and slots of snap "firefox"
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Set automatic aliases for snap "firefox"
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Setup snap "firefox" aliases
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Run post-refresh hook of "firefox" snap if present
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Start snap "firefox" (737) services
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Remove data for snap "firefox" (728)
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Remove snap "firefox" (728) from the system
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Clean up "firefox" (737) install
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Run configure hook of "firefox" snap if present
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Run health check of "firefox" snap
Done    yesterday at 17:01 CET  yesterday at 17:01 CET  Handling re-refresh of "firefox" as needed

......................................................................
Handling re-refresh of "firefox" as needed

2021-11-24T17:01:50+01:00 INFO No re-refreshes found.

I will get back to you with 344 and its attached crash as it happened on a different machine.

In case it matters: despite the few hours delay between the snap refresh and the crash, Firefox was unused during that time and the crash occurred a few minutes or seconds once it started being actively used.

Flags: needinfo?(achats+bugzilla)

(In reply to Olivier Tilloy from comment #44)

Thanks! Can you share the output of snap tasks 250 and snap tasks 344?

And the 344:

snap tasks 344
Status  Spawn                   Ready                   Summary
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Ensure prerequisites for "firefox" are available
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Download snap "firefox" (737) from channel "latest/beta"
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Fetch and check assertions for snap "firefox" (737)
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Mount snap "firefox" (737)
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Run pre-refresh hook of "firefox" snap if present
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Stop snap "firefox" services
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Remove aliases for snap "firefox"
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Make current revision for snap "firefox" unavailable
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Copy snap "firefox" data
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Setup snap "firefox" (737) security profiles
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Make snap "firefox" (737) available to the system
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Automatically connect eligible plugs and slots of snap "firefox"
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Set automatic aliases for snap "firefox"
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Setup snap "firefox" aliases
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Run post-refresh hook of "firefox" snap if present
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Start snap "firefox" (737) services
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Remove data for snap "firefox" (728)
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Remove snap "firefox" (728) from the system
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Clean up "firefox" (737) install
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Run configure hook of "firefox" snap if present
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Run health check of "firefox" snap
Done    yesterday at 14:17 CET  yesterday at 14:17 CET  Handling re-refresh of "firefox" as needed

......................................................................
Handling re-refresh of "firefox" as needed

2021-11-24T14:17:51+01:00 INFO No re-refreshes found.

-> And the related crash: https://crash-stats.mozilla.org/report/index/bp-ee61eb10-7489-4724-8421-46fca0211124

In case it matters: despite the few hours delay between the snap refresh and the crash, Firefox was unused during that time and the crash occurred a few minutes or seconds once it started being actively used.

Thanks, it does matter indeed. That's what I have been observing too. Crashes happen upon user interaction after the update.

raycy.jp: it was pointed out in comment 42 that yours is bug 1720573. This bug is tracking a snap-specific problem, and you are running Firefox nightly, for which there is no snap package, so that's clearly a different issue. Please share your comments and crash reports on that other bug, to avoid additional confusion. Thanks.

Flags: needinfo?(raycy.jp)

Quoted both aspects there: bug 1720573 comment 42

Flags: needinfo?(raycy.jp)

(In reply to Olivier Tilloy from comment #37)

In light of this last comment, I'm suspecting this might indeed be caused by the firefox snap (or the gnome platform snap which it depends on) being refreshed while it's running. There is work ongoing to prevent this, and an experimental feature already allows this, but it's not enabled by default, see https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736 for details.
[...]
And as a workaround until this is properly fixed in snapd, I strongly suggest turning on the experimental feature:

snap set core experimental.refresh-app-awareness=true

I confirm that this workaround solves the issue for me. I didn't get any crashes for a few days despite some updates to the snap package I have been using.

(In reply to Olivier Tilloy from comment #37)

And as a workaround until this is properly fixed in snapd, I strongly suggest turning on the experimental feature:

snap set core experimental.refresh-app-awareness=true

This workaround doesn't seem to work very well. I've just got another crash for this reason. I think I've seen it warning me about there is a pending upgrade for several days, but it doesn't automatically upgrade after I close Firefox. So today it probably decided that it is the time to upgrade even if I have this flag enabled and Firefox is still running.

To be fair, in majority of time the system is running, Firefox is running as well. It is usually the first app I open after boot (other than all the autostart ones), and the last app I close before shutdown, so it may not have much time. But I would hope it to be able to do the switch at the very time Firefox is closed...

Crash Signature: libxul.so@0x6813b61 | libxul.so@0x422f5c6 | libxul.so@0x422f1f8 | libxul.so@0x64065c3 | libxul.so@0x72b900f | libxul.so@0x92ce433 ] → libxul.so@0x6813b61 | libxul.so@0x422f5c6 | libxul.so@0x422f1f8 | libxul.so@0x64065c3 | libxul.so@0x72b900f | libxul.so@0x92ce433 ] [@ libxul.so@0x5fd419e | libxul.so@0x52c030c ] [@ libxul.so@0x5fd6d1e | libxul.so@0x52be9ec ] [@ libxul.so@0x607d4be | …
status-firefox97: --- → affected
status-firefox98: --- → affected

(In reply to Olivier Tilloy from comment #37)

In light of this last comment, I'm suspecting this might indeed be caused by the firefox snap (or the gnome platform snap which it depends on) being refreshed while it's running. There is work ongoing to prevent this, and an experimental feature already allows this, but it's not enabled by default, see https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736 for details.

To everyone affected, next time you hit a similar crash, can you share the output of snap changes to confirm that the crash happened shortly after either the firefox snap or the gnome-3-38-2004 snap were updated?

And as a workaround until this is properly fixed in snapd, I strongly suggest turning on the experimental feature:

snap set core experimental.refresh-app-awareness=true

I got the crash in a VM a few minutes ago, and snap changes does mention firefox as well as gnome-3-38-2004

I think the worst is that it's crashing the main process, and so we can't show about:restartrequired.

I'm a little confused by this — I thought one of the core features of Snap packaging is that each version is installed at its own path and isn't modified, meaning that if you're running from /snap/firefox/973 (for example), the sandbox will continue using /snap/firefox/973, and similarly for any dependencies. But the description of refresh-app-awareness implies something different.

In any case, given that the problem is something about fonts, I was wondering if maybe the firefox process is seeing an incoherent view of fontconfig cache vs. font files. On my system I notice that /usr/share/fonts is bind-mounted from the real one, but /var/cache/fontconfig is from the core20 snap and is an empty directory. But my home directory is present, including ~/.cache/fontconfig, so I think that should work? (In more detail: straceing fc-match shows that it normally uses the system cache only, but if I unshare -rUm and mount -t tmpfs tmpfs /var/cache/fontconfig to simulate the snap situation then it uses the cache in my home directory and seems to still work. But I haven't tried complex queries, and I don't know how various kinds of update would affect that.)

(In reply to Will May from comment #3)

I too have just started suffering from this problem, after having switched from using the deb version to the snap version. Given this theory that it's something to do with snap, I've spotted this suspect message in my kern.log - I guess 140160 was the Firefox process?

kernel: [166766.739545] audit: type=1400 audit(1635346324.148:806): apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/proc/140160/environ" pid=159703 comm="WRWorker#0" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

I think this happened after the crash, as follows: 140160 was the Firefox process, 159703 is the process cloned by the crash reporter to do crash reporting, which inherited the name of the thread that created it (the one where the crash happened), and it's trying to read info from the crashed process's procfs dir to include as supplementary information in the minidump.

Crash Signature: libxul.so@0x533664c ] [@ libxul.so@0x5eb6dbe | libxul.so@0x51ffe0c ] [@ libxul.so@0x607e26e | libxul.so@0x53373fc ] → libxul.so@0x533664c ] [@ libxul.so@0x5eb6dbe | libxul.so@0x51ffe0c ] [@ libxul.so@0x607e26e | libxul.so@0x53373fc ] [@ libxul.so@0x6083c4e | libxul.so@0x53365cc]

I see this crash about once or twice a day when I click and drag a tab to reorder them.

One of the comments above indicates that the workaround in the title does not solve the problem. I can confirm this. I have enabled the workaround on two machines, but still experience crashes related to "adding native font failed". I've had it happen probably a dozen times since I enabled the workaround. I also regularly check that I still have the workaround enabled...and check the crash report to confirm it is related to "adding native font failed".

I just experienced another crash. snap changes reports:

230  Done    today at 15:47 UTC  today at 15:47 UTC  Auto-refresh 5 snaps
231  Done    today at 15:48 UTC  today at 15:48 UTC  Remove vulnerable "snapd" snap
232  Done    today at 15:48 UTC  today at 15:48 UTC  Remove vulnerable "core" snap
233  Done    today at 15:49 UTC  today at 15:50 UTC  Refresh snap "firefox"

I believe the timing of this is that firefox crashed at 15:48. Since this happens regularly, I got into the habit of running "snap refresh" when firefox isn't running/crashes (which is what you see at 15:49). The same happened on another machine yesterday which is also configured to use the workaround.

I just experienced the same crash of the firefox snap, and the output of snap changes suggests that the refresh of the snapd snap at 2022-02-17T17:12:46+01:00 is what caused it.

Moving this to Widget:GTK because it seems to be potentially a fundamental thing with snap updates swapping out files underneath the browser (though we're not sure exactly what happens here?). But it's probably not a real graphics issue.

Component: Graphics: WebRender → Widget: Gtk

Just to try and add extra info here, I was hitting this issue and dug into it a bit over here, where my research made it really seem like this is an issue with accessing the font files themselves, with error codes looking a lot like "FF no longer has access to the file".

I think the general idea is here, but my gut feeling seems to be that it's less about files moving around and more about permissions on the font files themselves? But I know next to nothing about snap and how that stuff works.

The snapd team is working on the issue. It appears that when the snap is refreshed the directory /usr/share/fonts becomes empty, which trips FontContext::add_native_font() and causes the crash.

(In reply to Olivier Tilloy from comment #64)

The snapd team is working on the issue. It appears that when the snap is refreshed the directory /usr/share/fonts becomes empty, which trips FontContext::add_native_font() and causes the crash.

Is there a tracking bug for the snapd work?

I have hit this multiple times in the last couple of weeks, but don't remember it happening before then.

When I run Firefox from the command line and it crashes, I get this output:

ExceptionHandler::GenerateDump cloned child 6446
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

My latest crash was [@ libxul.so@0x608575e | libxul.so@0x53380dc ] with the error: adding native font failed: file=/usr/share/fonts/truetype/ubuntu/Ubuntu-R.ttf err=1

Another update installed in my back, another crash. This is much worse than the behavior we have with the deb package, since snap updates seems to be automatic and in background, and the crash is very hard.

(In reply to Daniel C from comment #65)

Is there a tracking bug for the snapd work?

This is being tracked at https://bugs.launchpad.net/snapd/+bug/1945697, although the title is a bit misleading because it suggests the crash happens only when snapd is refreshed. And there is a promising WIP branch at https://github.com/snapcore/snapd/pull/10676 that, in my tests, reliably fixes the problem.

(adding signature from dupe bug 1755836)

Crash Signature: libxul.so@0x533664c ] [@ libxul.so@0x5eb6dbe | libxul.so@0x51ffe0c ] [@ libxul.so@0x607e26e | libxul.so@0x53373fc ] [@ libxul.so@0x6083c4e | libxul.so@0x53365cc] → libxul.so@0x533664c ] [@ libxul.so@0x5eb6dbe | libxul.so@0x51ffe0c ] [@ libxul.so@0x607e26e | libxul.so@0x53373fc ] [@ libxul.so@0x6083c4e | libxul.so@0x53365cc] [@ libxul.so@0x611554e | libxul.so@0x541bd89 | libxul.so@0x541bcdb | libxul.so@0x566d944…
Flags: needinfo?(aosmond)

This problem should be gone now, it underlying cause was fixed in snapd 2.55 (see https://bugs.launchpad.net/snapd/+bug/1945697).

I'm still seeing instances of the crash though, e.g. https://crash-stats.mozilla.org/report/index/8bff991f-2d9a-4f9b-9df6-8cab50220603, but I suspect this is caused by the snapd update not having reached all users yet (in that specific instance the user was running Ubuntu 21.10, where the update isn't widely available yet, see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1965808).

I would be interesting for the crash reporter to include information about snapd and related content snaps (core20, gnome-3-38-2004, gtk-common-themes) when a crash is being reported from a snap version of firefox.

Marking as fixed per comment 72. If anybody hits this again with a version that is supposed to have been fixed, feel free to reopen.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.