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)
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?
Updated•13 years ago
|
Component: General → Web Apps
Product: Web Apps → Firefox
QA Contact: general → webapps
Comment 1•13 years ago
|
||
I can confirm this behavior specified in this bug.
Comment 2•13 years ago
|
||
I can't reproduce. I'll build a webapprt-stub that prints the unlink error.
Comment 3•13 years ago
|
||
(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
Comment 4•13 years ago
|
||
(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).
Comment 5•13 years ago
|
||
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.
Comment 6•13 years ago
|
||
I've managed to reproduce on Ubuntu, but not with my local debug build. I'm going to compile a release build.
Comment 7•13 years ago
|
||
Couldn't reproduce with the local release build. Weird.
| Reporter | ||
Comment 8•13 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•13 years ago
|
OS: All → Linux
| Reporter | ||
Comment 9•13 years ago
|
||
Feedback on that bug recommends to avoid using readlink("/proc/self/exe"… in most cases, even if their implementation wasn’t buggy.
Comment 10•13 years ago
|
||
Thank you John. We can use another solution then (that of bug 761516).
Comment 11•13 years ago
|
||
I can't reproduce now with bug 761516 patches landed. Could you verify?
| Reporter | ||
Comment 12•13 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•13 years ago
|
Comment 14•13 years ago
|
||
We should probably add a test case for this to MozTrap for an update test for Linux.
Flags: in-moztrap?(mar.castelluccio)
Comment 15•13 years ago
|
||
I've added a new test case: "Launch an application after a Firefox update".
Flags: in-moztrap?(mar.castelluccio) → in-moztrap+
Updated•13 years ago
|
QA Contact: jsmith
| Assignee | ||
Updated•10 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•