During the installation process, after a number of packages have been installed, the progress bar reaches 100% before installation is complete. The installer then starts to print: Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. It looks like the total download size is failing to account for some of the packages being installed.

over to Samir.

Reassigning to me.

*** Bug 84609 has been marked as a duplicate of this bug. ***

confirming based on the dupe...

*** Bug 84638 has been marked as a duplicate of this bug. ***

*** Bug 92609 has been marked as a duplicate of this bug. ***

I just installed trunk build 2001072821 and I do not see this problem any more.

Not sure why but the 2001072821 build did not have talkback (or at least I could not find it). The 2001072906 build has talkback again and now I'm getting those errors once more. Is this part of the problem?

Aha! Found the problem here. From config.ini (extracted from the net installer tar.gz): [Component5] Description Short=Quality Feedback Agent ; *** LOCALIZE ME BABY *** Description Long=Tool for reporting software crashes to Netscape Archive=talkback.xpi Install Size=33 Archive Size=1 Timeless told me that talkback is not posted right away because "it takes time to strip the binaries." The tar.gz is posted with Archive Size=1. This is fine if you don't download the talkback component, or if it is not on the server to download (as was the case when I posted my last comment). However, when you do download the talkback.xpi, it is definitely more than 1K and thus it causes the progress bar to exceed 100% since it is downloading more than expected. leaf: is this yours?

it's my problem, insofar as the unix automation doesn't regenerate the config.ini file for the stub installer when it replaces the dummy talkback file... are you using the net installer, or the full installer?

It's all in the net installer as far as I know. I'm assigning this to you for now, leaf.

the talkback.xpi file size has to be hard coded into the config.ini file for all platforms for mozilla. I thought it already was, but it seems I'm mistaken.

retargeting, accepting.

Bug 81242 is basically identical. Which one is to be duped?

*** Bug 81242 has been marked as a duplicate of this bug. ***

not blocking 0.9.5, moving to 0.9.6

The warning is coming up a few times even when I deselect QFA. Not 100s though, like when QFA is installed, just 2 or 3. So something else is still slightly off.

in bug 105732 this seems to cause a crash

*** Bug 83478 has been marked as a duplicate of this bug. ***

Duplicate bug 83478 had 6 duplicates and 1 vote by itself, this might be worth noting as it qualifies this bug as a mostfreq.

*** Bug 107285 has been marked as a duplicate of this bug. ***

Just tried to install mozilla the very first time, didn't get past about 300k of xpcom.xpi before the installer died. It said: ./mozilla-installer: line 55: 1586 Speicherzugriffsfehler ./mozilla-installer-bin --sync $@ Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. "Speicherzugriffsfehler" could be translated as memory access error When I restarted the installer, it happened again. My system: Debian 2.2r4 (with junkbuster installed, but no proxy selected for the mozilla install)

I just re-tried installation, with a freshly downloaded installer & a clean directory, this time it did work. I got a lot of messages like: Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. but the installer did continue all the way through. I suspect last time it got somehow irritated because I had closed the internet connection during the download (to switch to another provider).

9.7

Lately this is happening even without talkback selected, but only 5 or 6 times. Perhaps a rounding error, or other slight miscalculation.

*** Bug 111197 has been marked as a duplicate of this bug. ***

*** Bug 111768 has been marked as a duplicate of this bug. ***

leaf - this should be simple and has several dups - lets get this in 0.9.8

*** Bug 115079 has been marked as a duplicate of this bug. ***

it would be nice to get this fixed for 1.0.

This should be pretty simple to fix. I bet it has to do with the talkback.xpi sizes (compressed and expanded) being wrong in the config.ini file.

Suprsingly this WORKS FOR ME in build 2002012821, RH7.2. I have chosen Typycial installation and (for the first time ever) I have seen no warnings on exceeding this 100 limit. Is this a common experience now?

Unfortunately, no. I got the following errors with 2002-01-28-21 on Linux during a custom install (Navigator, MailNews, PSM and Talkback): Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed.

I saw it on one of 3 installs with the 1/28 nightly so it hasn't completely gone Install was custom with Navigator, Mail/News and Talkback selected

A follow-up to my comment 33: the same build installs without warnings if I choose a typical install (which is what andrzej was doing too).

The errors starts to be printed on the console as soon as the downloaded size is larger than the total size to be downloaded.

Nominating because this makes us look like morons. Leaf, can we just put a "guaranteed to be too big" size in there if we don't know the real size? No one will notice if the progress bar goes to 85 then the dialog disappears (they'll just think the last 15% was really fast), while it's impossible not to notice three hundred lines of error messages printed to stdout on every install.

nsbeta1- since this doesn't impact Netscape bits, only mozilla bits. leaf is swamped working on the win32 gmake system. cc'ing asasaki in case he has time after finishing his versioning changes.

*** Bug 135488 has been marked as a duplicate of this bug. ***

Below is a table comparing the size we specify in config.ini with the real size of the .xpi's. As can be seen, talkback.xpi is the big miss: it's specified as being 1k in config.ini while it really is 812k! The rest of the xpi's need minor adjustments as well. Can we please have this fixed ASAP? config.ini real size: ---------- ---------- Archive=browser.xpi Archive Size=7474 7488 config.ini real size: ---------- ---------- Archive=mail.xpi Archive Size=1832 1836 config.ini real size: ---------- ---------- Archive=psm.xpi Archive Size=754 760 config.ini real size: ---------- ---------- Archive=chatzilla.xpi Archive Size=102 108 config.ini real size: ---------- ---------- Archive=talkback.xpi Archive Size=1 812 config.ini real size: ---------- ---------- Archive=defleus.xpi Archive Size=7 8 config.ini real size: ---------- ---------- Archive=langenus.xpi Archive Size=558 564 config.ini real size: ---------- ---------- Archive=regus.xpi Archive Size=33 36 config.ini real size: ---------- ---------- Archive=venkman.xpi Archive Size=151 156 config.ini real size: ---------- ---------- Archive=inspector.xpi Archive Size=212 216

Don't forget that a K is 1024 bytes, not 1000. I get exactly the sizes in the config.ini when I look at ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-04-07-06-trunk/linux-xpi/ If you look at the above directory you can see the problem: talkback.xpi is created some time after the rest of them (since it's a donation from the Netscape commercial build). This has already been mentioned in this bug. I'm tired of the whining, taking the bug

Hardcoding the sizes I get from a Netscape commercial build plus about 1% for growth. Today's Netscape build has installed size 1940 and archive size 806. The mozilla windows installer apparently already takes this approach. I've updated the install size to current values, the archive size is still a few K higher than the actual value.

Comment on attachment 78135 [details] [diff] [review] Hardcode real sizes from current builds (plus 1%) r=syd

dveditz, the "real size" I specified is the size that "ls -ks" tells me for the .xpi files and the -k option is: -k, --kilobytes like --block-size=1024 I don't know how mozilla calculates the file size, but I actually trust ls more in this case. This bug also shows up when you don't intall talkback, although fewer errors are printed, so to me it makes sense that the other sizes are somewhat wrong too.

Okay, I should read the manpage for ls better next time. Sorry for that.

*** Bug 137832 has been marked as a duplicate of this bug. ***

*** Bug 139223 has been marked as a duplicate of this bug. ***

*** Bug 141161 has been marked as a duplicate of this bug. ***

I just downloaded and did a ``complete'' install of Mozilla 1.0 Release Candidate 1 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 from ftp://archive.progeny.com/mozilla/releases/mozilla1.0rc1/mozilla-i686-pc-linux-gnu-1.0rc1-installer.tar.gz . I see the bug is still here. The progress indicator gives a number that's well over 100 percent, and I get over 50 copies of the error message ``Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed.'' . I agree with Akkana. if we can't automate getting the correct numbers, the next best thing is to hardcode numbers that are 15 % too big.

This is fixed on the branch, not yet on the trunk. Or at least the bulk of this attributable to talkback is fixed. Now that that's out of the way maybe we'll find smaller problems hiding.

verified on branch build 2002052909

I am afraid that I probably see the same bug in mozilla 1.1 beta installer. While trying to install the talkback-enabled network installer (the one that fetches xpi files via network), it spews out the following messages. The installation seemed to work, though. (I am using 1.1b thus installed) But it sure will be nice to wipe out this bug since the uncertainty of installation success gives very bad feeling to new users. Messages I found out after leaving the console for a while. ... many repetitions of the following lines. Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed. Warning: MOZILLA_FIVE_HOME not set. duron:/home/ishikawa/mozilla-installer# I don't know what MOZILLA_FIVE_HOME not set WARNING is. But again, this may leave a very uncomfortable feeling to a new user.

Comment on attachment 78135 [details] [diff] [review] Hardcode real sizes from current builds (plus 1%) This patch got sr= as part of bug 125106. It was never checked in because it was wrapped up in that big scary fix that I'm waiting for 1.2a for, but this part should probably go in by itself.

If this has reviews, why not check it in now and make 1.1 look good instead of waiting for 1.2a and making 1.1 look stupid. This bug is more than a year old now, very visible and the fix is trivial ...

Comment on attachment 78135 [details] [diff] [review] Hardcode real sizes from current builds (plus 1%) a=asa (on behalf of drivers) for checkin to 1.1

Checked into 1.1

verified on build 2002080902-1.1