Closed Bug 1456327 Opened Last year Closed Last year

Unable to start firefox snap with edge channel (revision81)

Categories

(Release Engineering :: Release Automation: Other, defect)

defect
Not set

Tracking

(firefox60 fixed, firefox61 fixed)

RESOLVED FIXED
Tracking Status
firefox60 --- fixed
firefox61 --- fixed

People

(Reporter: extraymond, Assigned: jlorenzo)

References

()

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180419200216

Steps to reproduce:

Launching firefox from either launcher or with snap run firefox.


Actual results:

Firefox failed to launch with the following error message:

/snap/firefox/81/bin/desktop-launch: line 427:  6025 Aborted                 ln -sfn $REALHOME/.config/ibus/bus $IBUS_CONFIG_PATH
ExceptionHandler::GenerateDump cloned child 6029
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
/snap/firefox/81/crashreporter: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory

I'm not sure this is error with ibus or libgtk though.
If any additional info needed let me know.
Thanks.


Expected results:

Able to launch without problem.
Component: Untriaged → Release Automation
Product: Firefox → Release Engineering
QA Contact: catlee
Version: 60 Branch → unspecified
Thanks for the report! I don't know what's happening yet. For the record, revision 81 is Firefox 60.b15[1].

I doubt libgtk-3 is the culprit here. It's packaged in Ubuntu Xenial[2] as libgtk-3-0[3], which we did install in the b15 snap[4]. I didn't see ibus being installed, we just downloaded that ibus-gtk3_1.5 package[5], but I didn't see it being unpacked anywhere. 

We didn't change the recipe to make snaps recently. It's either something that changed in Firefox or in that "desktop-gtk3" snap-specific dependency[6]. Ken, while we check on our end, are you aware of some recent changes in "desktop-gtk3"?

[1] https://tools.taskcluster.net/groups/U-wG0qa_S6mE8VhsTRmt_w/tasks/BCHOLepgSvaIjLjN8vIAlQ/runs/0/logs/public%2Flogs%2Flive_backing.log#L867
[2] https://github.com/snapcore/snapcraft/blob/1404110cb2987fc794d82f71ae75b15a32fa498b/docker/stable.Dockerfile#L1
[3] https://packages.ubuntu.com/xenial/amd64/libgtk-3-0/filelist 
[4] https://tools.taskcluster.net/groups/O607MSw1T46go1vCaaIinA/tasks/JFj-vckNTQivbhz-1ZWI8A/runs/0/logs/public%2Flogs%2Flive.log#L4427
[5] https://tools.taskcluster.net/groups/O607MSw1T46go1vCaaIinA/tasks/JFj-vckNTQivbhz-1ZWI8A/runs/0/logs/public%2Flogs%2Flive.log#L6488
[6] https://searchfox.org/mozilla-central/rev/8f06c1b9a080b84435a2906e420fe102e1ed780b/taskcluster/docker/firefox-snap/snapcraft.yaml.in#55
Flags: needinfo?(ken.vandine)
Thanks! I'll revert to 80 which works fine.


Forget to report my os environment!

* OS: ubuntu 18.04 64bit
* Snapd:  2.32.5+18.04
* D.E: Tried both stock(gnome) and Communitheme

A side note which I think might relate to this issue, not sure if I have to report this to another bug because I think these too might relate to each other.
Since I'm in a CJK(Chinese mainly) locale environment, my input method is ibus which needs select buffer queue (phonetic input methods) for forming the correct word, which isn't always working fine with snap apps.
Earlier version of snapd allowed user to use ibus with select queue but the window will always be sticked to the bottom left of the app window. While this is fixed very recently, I've found that with firefox from the stable channel, I'm able to use ibus perfectly. However, when migrating to beta channel, ibus is not activated at all when typing inside firefox.

Given the above experience and the error log citing ibus when firefox crashed at launch, I think this might be related to how ibus-gtk-snap app reacts to each other. Hope this helps bisecting bugs.
Thank you for the extra information. This looks related to the current issue. Julien, are you aware of major changes related ibus in Firefox, recently?
Flags: needinfo?(jcristau)
I don't know anything about this.
Flags: needinfo?(jcristau)
Duplicate of this bug: 1456431
Bug 1456431 comment 1 has an interesting backtrace. I don't think something related to it changed in b15.
Status: UNCONFIRMED → NEW
Ever confirmed: true
NI'ing Olivier who may have context on this too. See question in comment 1.
Flags: needinfo?(olivier)
(In reply to Johan Lorenzo [:jlorenzo] from Bug 1456431 comment #2)
> I don't think something changed in bindtextdomain. That's a library we imported in tree in 
> bug 724531. It hasn't changed since then

The bindtextdomain.so library file only just appeared in revision 81.

> diff --brief -r /snap/firefox/80 /snap/firefox/81
> Only in /snap/firefox/81: bindtextdomain.so


> diff /snap/firefox/80/bin/desktop-launch /snap/firefox/81/bin/desktop-launch
> 38a39,41
> if [ -f $SNAP/bindtextdomain.so ]; then
>   export LD_PRELOAD=$LD_PRELOAD:$SNAP/bindtextdomain.so
> fi
I don't the bindtextdomain change is causing this, but we did recently land a change in the desktop-gtk3 helper specifically fixing to get ibus working in the snap.
Flags: needinfo?(ken.vandine)
I see the `ln` call was moved from launcher-specific[1] to desktop-exports[2] (like the `mkdir -p` call in bug 1456431 comment 4). Just like in this comment, can I target a specific revision in our snapcraft manifest in order to do a regression window?


[1] https://github.com/ubuntu/snapcraft-desktop-helpers/pull/106/files#diff-334896075ffe7ba59b8ce9630fff01a6L33
[2] https://github.com/ubuntu/snapcraft-desktop-helpers/pull/106/files#diff-1a00de5bae9bcc5c074586e13fc04bf3R367
Flags: needinfo?(ken.vandine)
(In reply to Johan Lorenzo [:jlorenzo] from comment #10)
> I see the `ln` call was moved from launcher-specific[1] to
> desktop-exports[2] (like the `mkdir -p` call in bug 1456431 comment 4). Just
> like in this comment, can I target a specific revision in our snapcraft
> manifest in order to do a regression window?
> 
> 
> [1]
> https://github.com/ubuntu/snapcraft-desktop-helpers/pull/106/files#diff-
> 334896075ffe7ba59b8ce9630fff01a6L33
> [2]
> https://github.com/ubuntu/snapcraft-desktop-helpers/pull/106/files#diff-
> 1a00de5bae9bcc5c074586e13fc04bf3R367

You can add the following to the parts section:

desktop-gtk3:
  source-commit: <commit>

That will pull helpers source from a specific commit.
Flags: needinfo?(ken.vandine)
Duplicate of this bug: 1456431
I confirm the start up crash was caused by the PR called out in comment 10. If you want to try this too:
1. I kicked off a new snap build at [2]. See that it's exactly 60.b15, except I added:
> sed -ri \"s/parts:/parts:\\n  desktop-gtk3:\\n    source-commit: 6a600b00773e8e4624aa12ee1f8e013ba9f2fc03/\" snapcraft.yaml.in
in the command. This set desktop-gtk3 to the last commit before PR106. 
2. Install the created snap[4]:
> snap install --dangerous /path/to/target.snap
3. Run the snap:
> firefox

See the there's no more stracktraces spewed out. Firefox starts and the windows are opened. However, they remain black and are never rendered. Here are the logs I get:

> /snap/firefox/x3/bin/desktop-launch: line 174: /home/ubuntu/snap/firefox/common/.config/user-dirs.dirs: No such file or directory
> cp: cannot create regular file '/home/ubuntu/snap/firefox/common/.config/': Not a directory
/snap/firefox/x3/bin/desktop-launch: line 177: /home/ubuntu/snap/firefox/common/.config/user-dirs.dirs.md5sum: No such file or directory
> /snap/firefox/x3/bin/desktop-launch: line 177: /home/ubuntu/snap/firefox/common/.config/user-dirs.locale.md5sum: No such file or directory
> Gtk-Message: Failed to load module "canberra-gtk-module"
> Gtk-Message: Failed to load module "canberra-gtk-module"
> Gtk-Message: Failed to load module "canberra-gtk-module"
> Gtk-Message: Failed to load module "canberra-gtk-module"
> [GFX1-]: Failed to lock new back buffer.
> [GFX1-]: Failed to lock new back buffer.
> *and more GFX logs afterwards*

For the record, I made another b15 build, with desktop-gtk3 being on the latest master[5]. I still see the same stacktraces as initially reported.

I'm gonna find the last working commit desktop-gtk3 to get Firefox beta in a working state. Ken, are you able to reproduce this on your side? I'm running Ubuntu 16.04 LTS with the latest patches applied.

[1] https://github.com/ubuntu/snapcraft-desktop-helpers/pull/106
[2] https://tools.taskcluster.net/groups/PZwr-HQOTOilfbTneX5yTQ/tasks/PZwr-HQOTOilfbTneX5yTQ/details
[3] https://github.com/ubuntu/snapcraft-desktop-helpers/commit/6a600b00773e8e4624aa12ee1f8e013ba9f2fc03
[4] https://queue.taskcluster.net/v1/task/PZwr-HQOTOilfbTneX5yTQ/runs/0/artifacts/public/build/target.snap
[5] https://tools.taskcluster.net/groups/dPrGfoeoSrKdwIYNXwGZyw/tasks/dPrGfoeoSrKdwIYNXwGZyw/details
Flags: needinfo?(ken.vandine)
(In reply to Johan Lorenzo [:jlorenzo] from comment #13)
> See the there's no more stracktraces spewed out. Firefox starts and the
> windows are opened. However, they remain black and are never rendered. Here
> are the logs I get:
> [..]
> I'm gonna find the last working c(In reply to Johan Lorenzo [:jlorenzo] from comment #13)
> See the there's no more stracktraces spewed out. Firefox starts and the
> windows are opened. However, they remain black and are never rendered. Here
> are the logs I get:
> [..]
> I'm gonna find the last working commit desktop-gtk3 to get Firefox beta in a
> working state. Ken, are you able to reproduce this on your side? I'm running
> Ubuntu 16.04 LTS with the latest patches applied.


Please ignore these part of my comment. I think something went wrong on my Ubuntu VM. I don't manage to repro the black window anymore. Moreover, 60.b14 was built on top of desktop-gtk3 6a600b00773e8e4624aa12ee1f8e013ba9f2fc03. extraymond and Kestrel both said this revision was working for them. It is working on my machine too. I guess I just had an environment issue after all. I just made a patch to pin desktop-gtk3.ommit desktop-gtk3 to get Firefox beta in a
> working state. Ken, are you able to reproduce this on your side? I'm running
> Ubuntu 16.04 LTS with the latest patches applied.


Please ignore these part of my comment. I think something went wrong on my Ubuntu VM. I don't manage to repro the black window anymore. Moreover, 60.b14 was built on top of desktop-gtk3 6a600b00773e8e4624aa12ee1f8e013ba9f2fc03. extraymond and Kestrel both said this revision was working for them. It is working on my machine too. I guess I just had an environment issue after all. I just made a patch to pin desktop-gtk3.
Assignee: nobody → jlorenzo
Flags: needinfo?(olivier)
Flags: needinfo?(ken.vandine)
I should have done this earlier: I set the beta track back to revision 80 (60.0b14). Next snap build is a release cnadidate one. It will be sent to the candidate and the beta track.
Comment on attachment 8971506 [details]
Bug 1456327 - Snap: pin desktop-gtk3 dependency for causing start up crash

https://reviewboard.mozilla.org/r/240272/#review246072

Go for it
Attachment #8971506 - Flags: review?(sfraser) → review+
Pushed by jlorenzo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4bb7dc02d405
Snap: pin desktop-gtk3 dependency for causing start up crash r=sfraser
https://hg.mozilla.org/mozilla-central/rev/4bb7dc02d405
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
(In reply to Johan Lorenzo [:jlorenzo] from comment #16)
> Next snap build is a release cnadidate one. It will be sent to
> the candidate and the beta track.

RC1 was released yesterday but the Snap candidate and beta channels are still 60.0b14.
Flags: needinfo?(jlorenzo)
Correction: The candidate is still 59.0.2.
Thank you Kestrel for calling out. I really appreciate the bugs and discrepancies you find :D Please keep them coming :)

That's a bug in our release process. I filed bug 1459222 to track this. I'm sorry to say, I won't be able to release the Snap before next Wednesday (release day). To sum up, the release process is frozen at the time we kick a release off. Sorry for the inconvenience, we can have this fixed for 61.0rc.
Flags: needinfo?(jlorenzo)
See Also: → 1459222
You need to log in before you can comment on or make changes to this bug.