Closed Bug 574915 Opened 15 years ago Closed 15 years ago

Firefox upgrade from functional 3.6.3 to 3.6.4 kills Firefox install

Categories

(Toolkit :: Application Update, defect)

1.9.2 Branch
x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 315278

People

(Reporter: charles.scripter, Unassigned)

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 is killed by upgrade to 3.6.4 Puppy Linux 4.3.1 Patch upgrade failed -- Firefox performed a full upgrade, after which it failed to load or operate. Command line launch reports: # firefox /usr/lib/firefox/run-mozilla.sh: line 131: 9232 Bus error "$prog" ${1+"$@"} Note: a similar problem occurred in the recent Thunderbird upgrade -- perhaps a common cause? Reproducible: Always
Component: Installer → Application Update
Product: Firefox → Toolkit
QA Contact: installer → application.update
Version: unspecified → 1.9.2 Branch
Please attach (using the 'Add an attachment' link above) the following files from an affected installation located in the installation directory: active-update.xml navigate to the updates subdirectory last-update.log and backup-update.log navigate to the 0 subdirectory under updates update.status and if present update.log
Attached file Requested log files
It appears that browser.jar in the chrome directory is not the same as the browser.jar that is distributed by Mozilla. Did you modify it or any other files? It appears that when applying the complete update that it was unable to add libxul.so though why it was unable to add it on Linux makes very little sense. Could you check the permissions of libxul.so?
Permissions for libxul.so (don't know why I see 2 folders -- but root has write permission on both copies of the file): # find | grep libxul.so ./usr/lib/firefox-3.6/libxul.so ./usr/lib/firefox/libxul.so # ls -la usr/lib/firefox/libxul.so -rwxr-xr-x 1 root root 14757340 2010-05-04 22:05 usr/lib/firefox/libxul.so # ls -la usr/lib/firefox-3.6/libxul.so -rwxr-xr-x 1 root root 12941832 2010-03-04 08:04 usr/lib/firefox-3.6/libxul.so Re modifications: The only special modification that I made was using "about:config", to set: browser.cache.disk.capacity;20480 browser.cache.disk.parent_directory;/dev/shm This was done because Firefox was not obeying cache size limits under preferences (it was set to 20MB, it would often bloat to well in excess of 100MB -- requiring manual deletion to remove) BTW: I'm going to make a backup, and will try installing 3.6.6 (on the off chance that some mod in 3.6.4 was unstable, and has been superseded in 3.6.6). Hopefully will report back in a few minutes.
Also, are you using sudo or su to run Firefox to update? I ask because that has caused problems in the past. If you aren't, after making sure that 3.6.6 works please try installing 3.6.4 and updating to 3.6.6 from 3.6.4. Thanks
Hi Robert, I used "Help/Check for Updates" to update (in Puppy Linux, the default/only user is already root). Here's a puzzler... I used "check for updates" and it downloaded the full install. It installed correctly, and I am writing this from Firefox 3.6.6 right now. I wonder if the attempted "partial" update crashed something?... The problem with trying to update 3.6.4 to 3.6.6 is that my Firefox in that case is completely kaput -- won't come up at all, just the command error I reported -- is there a command line Firefox command that will allow me to perform an update, without the browser coming up? If so, I'd be happy to give it a try. BTW, my thanks to you and the rest of the Firefox guys!
There isn't a command line to perform all of the steps for an update. This could have happened due to low disk space as well... could you post how much free space and if you freed up any space after this happened? Is the original installation working now? Thanks
I believe that I had about 50MB free when I started the operation (one simple implementation of Puppy Linux uses a file as a user volume filesystem). I made a copy of my 3.6.3 pre-upgrade volume to try some tests on (I was going to try installing 3.6.4 again). It currently has 57MB free. The 3.6.3 to 3.6.6 version upgrade worked -- but I have loaded an older save, with 3.6.3 to test your suggested upgrade. Approximately how much space does the upgrade take (my guess is that the maximum should just after the packaged is decompressed, and before it has deleted the tarball). I can try pinching the disk space to just below that limit, to see if I can replicate the error that way (BTW, perhaps Firefox can check available space before initiating installation -- that should prevent disk space as a source of crashes).
There is already a bug on calculating the needed disk space and checking the available disk space. An update can take up approximately as much as the original installation which for 3.6.6 is approximately 30 MB.
OK, I just located and grabbed "firefox-3.6.3-3.6.4.partial.mar", but it's not obvious how I would force Firefox to load/upgrade to this (bash doesn't know how to run it). Is there a command within Firefox to point to a .mar (bypassing the Mozilla preferred upgrade)? I can trash this system I'm working on (it's a test bed), so we need not worry about corrupting things beyond repair. I thought it might be instructive to see why the simple upgrade failed, if I can force that to run (without permitting Firefox to attempt a full upgrade after the failure).
If you want to try to manually apply the mar there are instructions available https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file
Update: I think I have located the instructions. Will attempt to upgrade to 3.6.4 shortly.
Which instructions are you using if they aren't the ones that I linked to?
Sorry, I located and apparently posted at the same moment you did. I found the same instructions (same page). Will test shortly.
OK, perhaps I'm not doing this correctly. I used the suggested /app-update/ directory. I copied updater.ini and updated from /usr/lib/firefox, into /app-update/. I copied "firefox-3.6.3-3.6.4.partial.mar" to update.mar in that same folder. I changed my default directory to /usr/lib/firefox/ and tried "/app-update/updater /app-update/". The log file reports: SOURCE DIRECTORY /app-update/ failed: 6 calling QuitProgressUI
(In reply to comment #15) > OK, perhaps I'm not doing this correctly. I used the suggested /app-update/ > directory. I copied updater.ini and updated from /usr/lib/firefox, into > /app-update/. I copied "firefox-3.6.3-3.6.4.partial.mar" to update.mar in that > same folder. I changed my default directory to /usr/lib/firefox/ and tried > "/app-update/updater /app-update/". Without the quotes? Try it without updater.ini. Just in case (though it doesn't seem to be the case) Firefox shouldn't be running as well. Not default directory but the current directory as in cd'ing into /usr/lib/firefox/.
Sorry...My error -- I misnamed the file "upgrade.mar" not "update.mar". The test of upgrade ran. I observed the installation of the 1.6MB upgrade consumed all of the 50+ MB free space, and promptly rebounded to 26MB (I have a free disk space counter on the desktop). The upgrade was performed while Firefox 3.6.3 was open -- I suspect that the browser will be dead once I shut it down. I can post the .log if you'd like to see it (it reports "failed 7" at the end) Note: I was able to perform a full upgrade to FF 3.6.6 in this amount of disk space. I will try clearing some more space, and testing again (but it will have to wait until tomorrow -- I'm reaching the point that I'm starting to make typos -- such as the first line...) Thanks for the help Robert!
No reason to attach the log... I'm sure it is the same as the previous log. Testing whether it succeeds with additional free space would be a good thing. Though it shouldn't matter on Linux, trying without Firefox open would also be a good thing.
OK, the previous patch crunched the Firefox. I restored and retested. I moved the update folder out of the main partition, and deleted some stuff, leaving me 82MB to start. I saw the transient space drop to ~60MB (I'm not sure how fast this tool is, or if I can determine the actual low-memory-point), then rebound to 82MB. The update apparently "worked" (as I'm writing from it right now), but I got the following error during the operation: # /mnt/sda2/app-update/updater /mnt/sda2/app-update/ (updater:11799): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed # I'm going to close for tonight. I'll keep this test bed in case you want log files to see what the error/warning above is.
If you could please try it again when you get a chance with the updater.ini to see if the assertion still occurs.
OK, I made another copy of the OS, this time with 61M free. Updating from 3.6.3 to 3.6.4: # df -h unionfs 310M 250M 61M 81% / I launched the updater: # cd /usr/lib/firefox # /mnt/sda2/app-update/updater /mnt/sda2/app-update/ (updater:6920): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed The update appears to have worked -- at least the Firefox functions at the limited level I tested it. I followed up with an update from 3.6.4 to 3.6.6 without observable errors -- also "last-update.log" also shows no errors for this process (and I'm writing from it right now). I'm going to attempt pinching the available space (say, 50MB, 40MB, ...) to see if I can identify the size at which a hard crash occurs.
The size won't be of interest since it changes for each update and we are going to have to calculate the size. From the info you have provided this is a duplicate of bug 315278. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
OK (too late). Well, I just tested it at 50MB, then 40MB free and it again seems to have correctly installed, but with the same error message -- I'm not sure why my early try completely crashed. with 50MB: (updater:12684): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed with 40MB: (updater:11614): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (I don't understand what the variable value following "updater:" is, but seems to change with each try) Is there any interest in the log files for these installs? (or should I purge the filesystem-files?)
The logs you've already attached will suffice and thanks again for testing this out so the source of the problem could be found.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: