Closed Bug 763192 Opened 13 years ago Closed 13 years ago

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

Categories

(Firefox Graveyard :: Web Apps, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: beta, Unassigned)

Details

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?
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.
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.
OS: All → Linux
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?
Keywords: qawanted
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)
Status: NEW → RESOLVED
Closed: 13 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+
QA Contact: jsmith
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.