The default bug view has changed. See this FAQ.

Linux webapp failing with ‘Couldn't remove the old webapprt-stub executable’

VERIFIED FIXED

Status

Firefox Graveyard
Web Apps
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: beta, Unassigned)

Tracking

unspecified
All
Linux
Bug Flags:
in-moztrap +

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120608 Firefox/15.0a2
Build ID: 20120608042008

Steps to reproduce:

Load .desktop shortcut, error message appears with ‘Couldn't remove the old webapprt-stub executable’

Permissions appear ok for the unlink in webapprt.cpp CopyAndRelaunch(), so not sure why this is failing.

One thing to note, this triggers each day after nightly updates and I manually have to copy the stub over the apps version - consider dropping the buildid comparison in webapprt-stub and look at major/minor version instead?

Updated

5 years ago
Component: General → Web Apps
Product: Web Apps → Firefox
QA Contact: general → webapps
I can confirm this behavior specified in this bug.
I can't reproduce. I'll build a webapprt-stub that prints the unlink error.
(In reply to Marco Castelluccio from comment #2)
> I can't reproduce. I'll build a webapprt-stub that prints the unlink error.

Try a test case like the following (I'll test this myself on a clean build):

1. Download the first nightly build that had linux support for web apps
2. Install some apps, launch those apps, and close them
3. Update Nightly to the latest version
4. Try re-launching each of those apps
(In reply to Jason Smith [:jsmith] from comment #3)
> (In reply to Marco Castelluccio from comment #2)
> > I can't reproduce. I'll build a webapprt-stub that prints the unlink error.
> 
> Try a test case like the following (I'll test this myself on a clean build):
> 
> 1. Download the first nightly build that had linux support for web apps
> 2. Install some apps, launch those apps, and close them
> 3. Update Nightly to the latest version
> 4. Try re-launching each of those apps

Just did that test case on Ubuntu 11 and confirmed that's definitely the right test case to use to test this. I did the following:

1. Downloaded and installed the 6/6/2012 nightly build
2. Went to apps.mozillalabs.com/appdir and installed Roundball
3. Launched Roundball and closed it
4. Updated this nightly build to the latest nightly
5. Re-launch Roundball

Result - The error indicated in this bug occurs (Couldn't remove the old webapprt-stub executable).
I've tried just modifying the buildid in applications.ini, and the webapprt-stub is correctly replaced. I've tested on Fedora, I'm going to test on Ubuntu and provide you a webapprt-stub that prints the unlink error if I can't reproduce.
I've managed to reproduce on Ubuntu, but not with my local debug build. I'm going to compile a release build.
Couldn't reproduce with the local release build. Weird.
(Reporter)

Comment 8

5 years ago
Could this be the cause? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1007089
That would make sense, as the /proc/self/exe is no longer valid therefore the unlink fails.

Updated

5 years ago
OS: All → Linux
(Reporter)

Comment 9

5 years ago
Feedback on that bug recommends to avoid using readlink("/proc/self/exe"… in most cases, even if their implementation wasn’t buggy.
Thank you John. We can use another solution then (that of bug 761516).
I can't reproduce now with bug 761516 patches landed. Could you verify?

Updated

5 years ago
Keywords: qawanted
(Reporter)

Comment 12

5 years ago
Yup, I believe this to be fixed, just tested with Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0a1 (2012-06-14)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Keywords: qawanted
Resolution: --- → FIXED
Marking as verified per comment 12.
Status: RESOLVED → VERIFIED
We should probably add a test case for this to MozTrap for an update test for Linux.
Flags: in-moztrap?(mar.castelluccio)
I've added a new test case: "Launch an application after a Firefox update".
Flags: in-moztrap?(mar.castelluccio) → in-moztrap+

Updated

5 years ago
QA Contact: jsmith
(Assignee)

Updated

a year ago
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.