Last Comment Bug 763192 - Linux webapp failing with ‘Couldn't remove the old webapprt-stub executable’
: Linux webapp failing with ‘Couldn't remove the old webapprt-stub executable’
Status: VERIFIED FIXED
:
Product: Firefox Graveyard
Classification: Graveyard
Component: Web Apps (show other bugs)
: unspecified
: All Linux
: -- normal
: ---
Assigned To: Nobody; OK to take it and work on it
: Jason Smith [:jsmith]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-09 07:04 PDT by John Drinkwater (:beta)
Modified: 2016-02-04 15:00 PST (History)
4 users (show)
mcastelluccio: in‑moztrap+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description John Drinkwater (:beta) 2012-06-09 07:04:51 PDT
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?
Comment 1 Jason Smith [:jsmith] 2012-06-09 11:26:16 PDT
I can confirm this behavior specified in this bug.
Comment 2 Marco Castelluccio [:marco] 2012-06-09 17:13:01 PDT
I can't reproduce. I'll build a webapprt-stub that prints the unlink error.
Comment 3 Jason Smith [:jsmith] 2012-06-09 23:34:44 PDT
(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 Jason Smith [:jsmith] 2012-06-09 23:49:51 PDT
(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 Marco Castelluccio [:marco] 2012-06-10 01:37:45 PDT
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 Marco Castelluccio [:marco] 2012-06-10 14:32:02 PDT
I've managed to reproduce on Ubuntu, but not with my local debug build. I'm going to compile a release build.
Comment 7 Marco Castelluccio [:marco] 2012-06-10 16:41:34 PDT
Couldn't reproduce with the local release build. Weird.
Comment 8 John Drinkwater (:beta) 2012-06-10 18:44:29 PDT
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.
Comment 9 John Drinkwater (:beta) 2012-06-11 02:35:19 PDT
Feedback on that bug recommends to avoid using readlink("/proc/self/exe"… in most cases, even if their implementation wasn’t buggy.
Comment 10 Marco Castelluccio [:marco] 2012-06-11 03:27:39 PDT
Thank you John. We can use another solution then (that of bug 761516).
Comment 11 Marco Castelluccio [:marco] 2012-06-13 08:59:01 PDT
I can't reproduce now with bug 761516 patches landed. Could you verify?
Comment 12 John Drinkwater (:beta) 2012-06-14 10:28:06 PDT
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)
Comment 13 Jason Smith [:jsmith] 2012-06-14 10:30:39 PDT
Marking as verified per comment 12.
Comment 14 Jason Smith [:jsmith] 2012-06-16 09:32:25 PDT
We should probably add a test case for this to MozTrap for an update test for Linux.
Comment 15 Marco Castelluccio [:marco] 2012-06-24 09:40:23 PDT
I've added a new test case: "Launch an application after a Firefox update".

Note You need to log in before you can comment on or make changes to this bug.