1757209 - Crash in [@ libxul.so@0x367f548 | libxul.so@0x367ef2b | libxul.so@0x1b13a28 | libxul.so@0x1b14616 | libxul.so@0x5e648d9 | libxul.so@0x6076c74 | libxul.so@0x60642ed | libxul.so@0x60aa724 | libxul.so@0x1b1a1d9 | libxul.so@0x1b197e8 | libxul.so@0x1b19348 ...

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[Olivier Tilloy]

Crashes started happening with the snap build of nightly with revision 1035, based on https://hg.mozilla.org/mozilla-central/rev/2eda0885cbada5c74f3b6c8d40b68ecb0f1826c1.

I can reliably trigger the crash by simply clicking the hamburger button to show the menu.

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/1a3ca7b2-7441-4521-a755-9f3d80220225

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so libxul.so@0x000000000367f548 
1 libxul.so libxul.so@0x000000000367ef2b 
2 libxul.so libxul.so@0x0000000001b13a28 
3 libxul.so libxul.so@0x0000000001b14616 
4 libxul.so libxul.so@0x0000000005e648d9 
5 libxul.so libxul.so@0x0000000006076c74 
6 libxul.so libxul.so@0x00000000060642ed 
7 libxul.so libxul.so@0x00000000060aa724 
8 libxul.so libxul.so@0x0000000001b1a1d9 
9 libxul.so libxul.so@0x0000000001b197e8 

Comment 1

[Olivier Tilloy]

When the crash happens, I'm seeing the following apparmor denials, which I'm not seeing with an earlier revision that doesn't crash:

feb 25 18:44:13 dantian audit[129230]: AVC apparmor="DENIED" operation="mknod" profile="snap.firefox_nightly.firefox" name="/dev/shm/wayland.mozilla.ipc.0" pid=129230 comm="Renderer" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
feb 25 18:44:13 dantian kernel: audit: type=1400 audit(1645811053.845:3711): apparmor="DENIED" operation="mknod" profile="snap.firefox_nightly.firefox" name="/dev/shm/wayland.mozilla.ipc.0" pid=129230 comm="Renderer" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

Comment 2

[Olivier Tilloy]

The regression was introduced by https://hg.mozilla.org/mozilla-central/rev/800e87c42d1d149f9c80c0d8f64a3984542d8165.
The implementation of GetSnapInstanceName() isn't correct, it will always return SNAP_INSTANCE_NAME aka MOZ_APP_NAME, instead of the value of g_getenv("SNAP_INSTANCE_NAME"). In my case, $SNAP_INSTANCE_NAME == firefox_nightly.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Okay, so nsToolkitProfileService::IsSnapEnvironment was wrong I suppose.

Snaps have no debug symbols? It'd be great to get a proper stack anyways :)

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1757209 - Don't hardcode snap instance name. r=OlivierTilloy,stransky

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/19c5c16d6554
Don't hardcode snap instance name. r=stransky

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0be131129953
Fix Android build.

Comment 7

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/19c5c16d6554
https://hg.mozilla.org/mozilla-central/rev/0be131129953

Comment 8

[Olivier Tilloy]

I can confirm the crash is gone in the latest nightly snap build (revision 1058).

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1756083

Comment 10

[Pascal Chevrel:pascalc (PTO until April 26)]

Olivier, does it happen only with nightly snaps or also with beta snaps? We have already built our release candidate so I'd like to know if this bug is a blocker for the release, thanks.

Comment 11

[Olivier Tilloy]

Fortunately, this only affected nightly snaps, the regression didn't make it into beta. Thus, not a blocker.

Comment 12

[Pascal Chevrel:pascalc (PTO until April 26)]

Thanks!