Can't install 6.1 beta, hangs after launch of setup file

VERIFIED FIXED in mozilla0.9.2


17 years ago
14 years ago


(Reporter: Jennifer Mulcaster, Assigned: Sean Su)


Windows 98
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: critical for 0.9.2, have patch r, sr and a)


(5 attachments)



17 years ago
Steps to reproduce
go to: Release
- Choose German windows
- download setup file on desktop
- launch set up and choose full install
- Installation hangs after only a few seconds.

Note: This is an additional install of the product. US English is in a separate 

Comment 1

17 years ago
Could be a network issue or installer recovery issue, according to Daniel. I was 
able to download the xpi's finally starting at about 11 a.m. My guess is that 
fewer people are downloading now???

Comment 2

17 years ago
adding loeb to cc: list. 

During this morning's conference call, Gregg, Reed and I saw this on DSL.
Keywords: nsbeta1, nsCatFood, rtm


17 years ago
Severity: normal → major

Comment 3

17 years ago
Changing summary, because i don't believe this is an L10N issue.

Also, hangs @ NIM, and "markers".
Summary: Can't install German 6.1 beta, hangs after launch of setup file → Can't install 6.1 beta, hangs after launch of setup file

Comment 4

17 years ago
I saw the same problem when I downloaded the Japanese PR1.
After I tried the second time, I could install it without any problems.
I used the DSL to install it.  

Comment 5

17 years ago
I actually saw the same thing when downloading it via DSL.  I ended up having to 
"end task".  Then relaunched N6Setup.exe and it picked up where I left off and 
eventually finished.

Comment 6

17 years ago
I encountered this problem simply by downloading N6SetupB.exe (25MB file) via
DSL directly from the public ftp site.  At one point the download just froze and
needed to be canceled, after that I was able to resume.  This happened twice, a
third time I was able to download the file completely w/o problems. 

Comment 7

17 years ago
Marking as DogFood because this happened to more than one person.

Note: This bug was originally entered against a download inside the firewall on
the internal LAN.
Keywords: nsdogfood

Comment 8

17 years ago
Happened to me on US Win2000 downloading English PR1 inside the firewall on
the internal LAN.

From the mail thread, it has happened Linux too reported by

There was also a reporte Mac crash (may not be related):
From: Paul Bergsagel <>
X-Mailer: Mozilla 4.77 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Netscape 6.1 PR1

I am sorry to post this here but I could not find the correct email
address for Netscape. Would you kindly forward this to the correct
person. I believe it is very important the correct person at Netscape
receive this email. Thanks.

On the Macintosh ( OS 8.6) Netscape 6.1 PR1 crashes upon install. Very
important installation information has been omitted from the release
notes. Until I paired down my extension set the program would crash
during the installation process.  Here is what I did. I turned off all
but the necessary extension to get a browser on to the internet and kept
Quicktime on (installation will fail if Quicktime is off).

Could someone update the release notes, or many will see this browser as
being unable to be installed. Thank you.

Paul Bergsagel.

Comment 9

17 years ago
catfood means polish, dogfood is irrelevant, and we don't use rtm for anything
anymore :-)

this problem is due to server issues, but I'll keep it open until they are resolved.
Keywords: nsbeta1, nsCatFood, nsdogfood, rtm → nsbeta1+
Target Milestone: --- → mozilla0.9.2

Comment 10

17 years ago
I'm able to reproduce a simular problem on Mac OS 8.6. The installation process
is frequently stalled and user must press pause/resume buttons to force the
install to continue. During the extracting phase, I get the following error:
Installation failed due to error -4.

Comment 11

17 years ago
Thanks for the feedback and interest Syd. Good to hear you are on this one.

IMHO this would be the best kinda of polish we could do before RTM, since this
is the first experience the outside world has with the product. A GREAT, above
par download and install would be fantastic for the product. Just my 2 cents.

Comment 12

17 years ago
For the record, I am unable to download and installer 6.1b1 from outside the
firewall.  DSL to a P3/600 win98SE box.  Download the stub, tell it to save the
xpi files in the default location, custom install minus all the 3rd party add
ins.  It hangs trying to download nim.xpi.  Tried it once via ftp (at less than
3KB/sec) and then twice via http (35 KB/sec, yeah!) and they all stalled out on
nim.xpi.  We should also take the ftp vs http download option out of the proxy
settings window so people know it's there and can choose which method of
downloading they want to use which would probably help even the load and make
the ftp download performance better and less prone to hanging.

And this should probably be another bug, but my % complete meter was up to 170%
every time when it stalled.

Comment 13

17 years ago
the percentage being > 100% is probably bug 83533.

Comment 14

17 years ago
Created attachment 38690 [details] [diff] [review]
patch to fix the shutdown() command.

Comment 15

17 years ago
Let's use socket symbols understood on all platforms or this won't compile on
other platforms.  :o)  

From a linux box's /usr/include/sys/socket.h:
/* The following constants should be used for the second parameter of
   `shutdown'.  */
  SHUT_RD = 0,      /* No more receptions.  */
#define SHUT_RD     SHUT_RD
  SHUT_WR,      /* No more transmissions.  */
#define SHUT_WR     SHUT_WR
  SHUT_RDWR     /* No more receptions or transmissions.  */

Also, for platforms that don't understand SHUT_{RD,WR} we should define them
just as SHUT_RDWR is currently defined:
#ifndef SHUT_RD
#define SHUT_RD 0

Comment 16

17 years ago
reassigning to myself.  I have a patch in testing right now.
Assignee: syd → ssu
Severity: major → critical
Component: Installer: XPInstall Engine → Installer

Comment 17

17 years ago
Created attachment 39079 [details] [diff] [review]
patch attempt #1


17 years ago
Blocks: 83533


17 years ago
Blocks: 83691


17 years ago
Blocks: 83692

Comment 18

17 years ago

Comment 19

17 years ago
just got r=sgehani too

Comment 20

17 years ago

Comment 21

17 years ago
a= for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989

Comment 22

17 years ago
Created attachment 39288 [details] [diff] [review]
additional patch that will increate TCP window size

Comment 23

17 years ago
Created attachment 39290 [details] [diff] [review]
same as the previous patch, but with a slight change

Comment 24

17 years ago
the default TCP window size is 8196.  The patch will increase it to 60k.  The 
window size is the size of the buffer for the created socket.  This buffer is 
used incoming data that can't be processed right away by the client.

Comment 25

17 years ago
*** Bug 86827 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
Created attachment 39457 [details] [diff] [review]
patch that contains just what we need to do this

Comment 27

17 years ago
ignore the change to nsXIEngine in the previous patch, that won't get checked in.

Comment 28

17 years ago
r=ssu on that last patch
Gah! That was me (Ben Goodger) commenting. using hyatt's machine. 

Comment 31

17 years ago
Whiteboard: critical for 0.9.2


17 years ago
Whiteboard: critical for 0.9.2 → critical for 0.9.2, have patch r, sr and a

Comment 32

17 years ago
be good if we could get this into 0.9.2 branch and trunk before monday morning
if its ready.


17 years ago
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 33

17 years ago
I talked to Syd.  He said that it's already checked in before the branch was 
cut.  marking this fixed.

Comment 34

17 years ago
verifying fix with new stub installer  
QA Contact: jimmylee → gbush

Comment 35

17 years ago
okay, landing this in the trunk and branch tonight -- seems like we are getting 
good results with the change in the window size.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.