97249 - Installer crashes after downloading

Status: VERIFIED DUPLICATE of bug 122918

(SeaMonkey :: Installer, defect)

Description

[Akkana Peck]

The installer crashes whenever I try to download a new build to either linux
machine on my home network (DSL, behind a LinkSys firewall/router, if that
matters).  The installer comes up, I select my choices, it downloads everything
(= long time) and then the installer crashes.  If I run it again it doesn't
notice that I've already downloaded the files, so I'm out of luck.

I've seen this with a commercial build last Thursday/Friday, and a mozilla build
today, on a Redhat 7.0 machine connected via SERA2 and a Redhat 7.1 laptop not
using SERA.

Stack trace (gdb is being its usual helpful self about line numbers, but perhaps
this will give someone a clue anyway):

#0  0x08061d9b in nsSocket::Send () at eval.c:41
#1  0x08062de4 in nsFTPConn::IssueCmd () at eval.c:41
#2  0x08062c20 in nsFTPConn::Close () at eval.c:41
#3  0x0805c109 in nsXIEngine::CheckConn () at eval.c:41
#4  0x0805bf62 in nsXIEngine::Download () at eval.c:41
#5  0x08057b63 in nsInstallDlg::PerformInstall () at eval.c:41
#6  0x08056e6d in nsInstallDlg::Next () at eval.c:41
#7  0x400c12b1 in gtk_marshal_NONE__NONE () at eval.c:41
#8  0x400f4916 in gtk_handlers_run () at eval.c:41
#9  0x400f3c3d in gtk_signal_real_emit () at eval.c:41
[ ... lots more gtk handlers ]

Comment 1

[Sean Su]

Over to syd since he's now deals with linux installer.  I'll try to see if I can 
get a test app under linux for you to try that prints out debug info.

If that stack trace is accurate, it's dying in our libxpnet code.

Akk, does the dialog stay up when it crashes?  If so, can you tell if it's 
showing the download progress bar or the xpinstall (file copying) progress bars?

Comment 2

[Akkana Peck]

The dialog doesn't stay up.  So far I always seem to be looking away from the
window when this happens, so I don't at this point know exactly what stage it's
in except that every time, just before I looked away, the download progress bar
was at 99% and the bar area was full, i.e. it was nearly finished downloading
and about to start installing.  (It sits at 99% for a while before it says it's
beginning the install.)

Comment 3

[Akkana Peck]

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

Comment 4

[Akkana Peck]

DSL isn't the culprit.  I just tried installing today's commercial build from
sweetlou on my laptop hooked into the internal LAN, and it crashes just the same.

The download finishes, a second dialog pops up briefly on top of the download
progress dialog -- looks like the second dialog has not much text and one big
button -- but I can't say for sure, because they both disappear almost
immediately to the crash.

Comment 5

[gabriel]

I've been seeing this or something similar as well for the past week or so on
Linux nightlies. In my case, if I choose to keep the xpi's on disk, then when I
restart the installer, it does install Moz.

Comment 6

[Jeremy M. Dolan]

Linux installer has been completly broken TWO WEEKS. This is still untargeted.

Comment 7

[Syd Logan]

This works for me, must be something specific on your machines, and I'd love to
find out what. I'm on RedHat 7.0, I downloaded the mozilla nightly (9/5/2001)
and placed it in my home dir in a directory called "foo", and installed into
another directory in my home directory called "bar" and it ran fine (both the
install and the browser launch). Akkana, are you installing over an old copy?
And when you install on the internal lan, is the stack trace also in the ftp
library? 

Jeremy, can I get some more details out of you? We run the installer here daily
for smoketesting, if Linux installer was completely broken I would have heard
about it by now. What are the particulars of your situation, perhaps therein
lies a clue to what might be happening.

Comment 8

[Jeremy M. Dolan]

Note when I mentioned this on IRC today, Dauphin tried and also had the crash.

I've tried various post-093 builds during the last few weeks and all of them
crash after download/before unpack.

This system was originally a slackware 7.1 install... C libs haven't changed or
anything like that though. 093 installed fine (if you don't count the > 1.0 assert)

Comment 9

[cls]

I see this on my RH6.2++ box with this morning's installer build.  I'm
attempting a fresh install of the browser, psm & talkbalk into ~/mozilla, which
does not exist .  It very briefly pops up a dialog saying
"Some files failed to download. Retrying" (or something like that) then
immediately segfaults.
After the initial failure, a second run of the installer works fine if you chose
the same config (ie the xpis are already downloaded).  If you add another xpi,
then the installer will install the already downloaded xpis and complain about
the new one.

RH6.2++ == RH6.2 + RH updates + glib/gtk-1.2.10-ximian.2

Comment 10

[Akkana Peck]

I've been installing into the default directory /usr/local/netscape or
/usr/local/mozilla, which does exist (it deletes contents before attempting the
install).  I haven't been checking "save installer modules on download", but
I'll start doing that if it means that I can rerun the installer and have a
chance of actually installing something the second time.

Comment 11

[Jeremy M. Dolan]

You don't even need to check that. I sucessfully installed through the crash
just rerunning.

A few more details on how I install...
  directory: ~/mozilla/6   [7...8...whatever day it is]
  custom: uncheck mailnews and chat, only nav,ssl,qfa installed

Comment 12

[gabriel]

I've been removing /usr/local/mozilla, then downloading all components except
chatzilla. It always crashes for me after downloading, I have to restart it to
continue the install.

Comment 13

[Syd Logan]

<Dauphin> 0x806b8a3 in nsSocket::Send (this=0xc515, aBuf=0xbfffcb30 "ABORT\r\n", 
<Dauphin>     aBufSize=0xbfffc6ec)
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/libxpnet/src/nsSocket.cpp:262
<Dauphin> 262         if (!aBuf || (aBufSize && (*aBufSize <= 0)) || mFd < 0)
<Dauphin> (gdb) print mFd
<Dauphin> Cannot access memory at address 0xc521
<syd> wow
<syd> the socket object is gone?
<syd> this looks whacky
<syd> er, "this"
<syd> 0xc515
<syd> that's probably memory in your video card :-)
<Dauphin> heh
<Dauphin> (gdb) print this
<Dauphin> $3 = (nsSocket *) 0xc515
<syd> stack is what?
<Dauphin> #0  0x806b8a3 in nsSocket::Send (this=0xc515, aBuf=0xbfffcb30
"ABORT\r\n", 
<Dauphin>     aBufSize=0xbfffc6ec)
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/libxpnet/src/nsSocket.cpp:262
<Dauphin> #1  0x806cf96 in nsFTPConn::IssueCmd (this=0x810aef0, 
<Dauphin>     aCmd=0xbfffcb30 "ABORT\r\n", 
<Dauphin>     aResp=0xbfffc730 "`8\r\b\030)\024@\224a\020\b\\", aRespSize=1024, 
<Dauphin>     aSock=0xc515)
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/libxpnet/src/nsFTPConn.cpp:40
  9
<Dauphin> #2  0x806cd06 in nsFTPConn::Close (this=0x810aef0)
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/libxpnet/src/nsFTPConn.cpp:319
<Dauphin> #3  0x8061bc5 in nsXIEngine::CheckConn (this=0x8100a20, URL=0x80763e0 "", 
<Dauphin>     type=0, myConn=0xbfffdc04, force=1)
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/unix/src2/nsXIEngine.cpp:417
<Dauphin> #4  0x80619cd in nsXIEngine::Download (this=0x8100a20, aCustom=1, 
<Dauphin>     aComps=0x8084b98)
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/unix/src2/nsXIEngine.cpp:340
<Dauphin> #5  0x805b4c2 in nsInstallDlg::PerformInstall ()
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/unix/src2/nsInstallDlg.cpp:555
<Dauphin> #6  0x805a241 in nsInstallDlg::Next (aWidget=0x80d33f8, aData=0x807be70)
<Dauphin>     at
../../../../../mozilla/xpinstall/wizard/unix/src2/nsInstallDlg.cpp:183
<Dauphin> #7  0x400a9c3f in gtk_marshal_NONE__NONE (object=0x80d33f8, 
<Dauphin>     func=0x8059b54 <nsInstallDlg::Next(_GtkWidget *, void *)>, 
<Dauphin>     func_data=0x807be70, args=0xbfffede0) at gtkmarshal.c:312

...

<Dauphin> if I skip the sending of the ABORT, then it dies off in libc. Stack is
about the same.

Comment 14

[Syd Logan]

Attachment: patch, should fix the problem

Comment 15

[Syd Logan]

patch does not help, something is getting clobbered before we reach here.

Comment 16

[Syd Logan]

I can't duplicate on Chris's machine either.

Comment 17

[Zack Weinberg (:zwol)]

I've been seeing this for awhile.  This is what gets printed right when
it crashes:

Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.
Segmentation fault

Unlike the original poster, if I then run the installer again, it picks up
where it left off and completes the installation.

Comment 18

[Jeremy M. Dolan]

This is severity: blocker, but no milestone... so it's not actually blocking
anything. Are we actually releasing 094 with an installer that crashes for 50%
of linux (UNIX?) users? The workaround is very non-obvious. If I were a user,
I'd redownload the thing before I re-ran a half complete (and probably corupt)
install.

Comment 19

[Akkana Peck]

Nominating for the branch.  It would be very sad to release a milestone that
many of us can't install ourselves.

Comment 20

[Syd Logan]

Attachment: Purify log from solaris

Comment 21

[Syd Logan]

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

Comment 22

[Jaime Rodriguez, Jr.]

Syd - What's the status on this one?

Comment 23

[Syd Logan]

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

Comment 24

[Syd Logan]

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

Comment 25

[Syd Logan]

Can those inside the firewall who can dupe this bug (I cannot) please go to:

http://jazz/users/syd/publish/moztest/

and grab the mozilla-installer-bin that is there, and see if it fixes things
(replace the mozilla-installer-bin) that you downloaded from mozilla.org, is
known to be compatible with mozilla 0.9.4 

Thanks,

syd

Comment 26

[Jaime Rodriguez, Jr.]

Pls provide the PDT with an ETA.

Comment 27

[Syd Logan]

No clue on the ETA.

Comment 28

[Akkana Peck]

Nope.  I downloaded today's commercial stub installer, extracted, downloaded
your mozilla-installer-bin and copied it on top of
netscape-installer/netscape-installer-bin, ran, and still got the crash.

The last message was a couple of Gtk-CRITICAL messages, file gtkprogress.c line
518 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <=
1.0 failed.  Then Segmentation fault at line 48 of netscape-installer.  Stack
trace is the same as Dauphin gave in the irc conversation quoted earlier in this
bug.

Comment 29

[Scott McPeak]

For those who can't reproduce, I'd mention you have to choose the Custom
option in the installer, and pick (I think) at least Navigator and Talkback.
See bug 100262, which reports the same problem, for repro steps.

Comment 30

[Jeremy M. Dolan]

I crash installing ONLY nav, no psm/qfa, so that's not it. I did get a dialog
that poped up before the crash with only Nav, though, but no text rendered on it.

Comment 31

[Jaime Rodriguez, Jr.]

When do we think this regression was introduced?

Syd - Pls provide an ETA, as soon as you can. We'd like this one, but we need to
know when it will land.

Comment 32

[Jaime Rodriguez, Jr.]

Samir - Any ideas here?

Comment 33

[Syd Logan]

Jaime, it'll get done when it gets done :-)

I can now dupe, I need to do a custom install to crash. Akk is now reporting she
does not crash if she does a typical install. So, the presumption is the crash
only happens with custom installs (in our case, deselecting mail news and talkback)

Comment 34

[Syd Logan]

hrmmm, you select only one file in custom and get a download display that says
it is installing file 1 of 5? Probably something to do with that. What a mess.

Comment 35

[Jeremy M. Dolan]

1 of 5 is due to the langpack, deflang, reg, xpcom.

this may be related to the > 100% problem, though. I'm now getting > 100% on the
progress meter WITHOUT psm, which was the original problem. Which is why that
should have been fixed long ago, it's hiding other problems.

Comment 36

[Syd Logan]

Ok, thanks for the update. Still trying to understand what "custom" install has
to do with this. I don't see the > 100% messages before I crash here.

Comment 37

[Akkana Peck]

When I tried installing with a commercial build, I saw the "not between 0 and 1"
gtk progress meter error before I crashed; when I tried with mozilla I didn't
see the error, but still crashed.  PSM was selected both times (actually, not
sure it's even optional in commercial builds, but I definitely had it selected
in the moz build).  Not sure what triggers that error.

Comment 38

[Syd Logan]

That error is caused by bad math -- the [0,1] range represents total number of
bytes downloaded / total bytes to download. It's not a fatal error for that
widget (progress bar), it basically screams and returns without doing anything.

Comment 39

[Scott McPeak]

Right, the [0,1] is bug 83478.  It appears to be orthogonal to the crash.

Comment 40

[Syd Logan]

Requested Pav run a purify build for me and select custom instead of typical,
and install PSM, chatzilla, Browser (don't isntall talkback or mail news). Maybe
we can see some clue doing that. He has 3 nsbranch+ bugs so we might need to
wait a bit, in the meantime I'll continue poking at this.

Comment 41

[Syd Logan]

I've got a fix, going to do some more testing and put up a patch later tonight...

Comment 42

[Syd Logan]

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

Comment 43

[Syd Logan]

Attachment: make sure to only CRC check files that got downloaded

Comment 44

[jag (Peter Annema)]

r=jaggles

Comment 45

[Syd Logan]

Dauphin reports this fixes his reproducible crash. 

Comment 46

[Jaime Rodriguez, Jr.]

Let's get the sr=, and the reviews in Patch Status, so we can take this one off
the radar.

Comment 47

[Daniel Veditz [:dveditz]]

This appears correct, but I wish you had cleaned up the code a little.
Particularly the one key line of this change which is now way too long. Looks
like you cribbed the following part of the if
  ((aCustom == TRUE && currComp->IsSelected()) || (aCustom == FALSE))
from elsewhere in the code, so you get "When in Rome..." points I guess. It'd be
clearer and shorter to say
   ( !aCustom || currComp->IsSelected() )
But then, I'm not a fan of (boolean == TRUE/FALSE) type tests.

Likewise the ugly cast on NULL in the for loop should have been a sign to do
things differently, like delete the explicit compare entirely:
  for(i = 0; currComp && i < MAX_COMPONENTS; i++) {
But I guess we should be conservative on the branch and you only touched a tab
on that line...

I really would like that long if() line broken on to multiple lines (and
preferably removing the explicit ==TRUEs). I'm not a nazi about the 80 columns
in our coding standard, but 145 columns is extreme.
With that one change, sr=dveditz

Comment 48

[Daniel Veditz [:dveditz]]

Comment on attachment 51039 [details] [diff] [review]
make sure to only CRC check files that got downloaded

marking review status to match r=/sr= comments in bug to satisfy PDT love affair with the patch manager

Comment 49

[Jaime Rodriguez, Jr.]

check it in - PDT+

Comment 50

[Syd Logan]

Fix checked in

Comment 51

[K'Trina Medina]

Grace and I could not reproduce this. Akkana, can you (or anyone that has
reproduced this) please verify this has been fixed? 

Comment 52

[sairuh (rarely reading bugmail)]

i haven't encountered either bug 97500 or a crash with recent trunk or
0.9.4-branch linux bits. marking verified.

Comment 53

[Akkana Peck]

It's ba-ack!  In today's stub installer build on mozilla.org.  I tried custom
(turn off mail) and browser only, and in both cases, the dialog sat for a long
time, not updating the progress bar at all, and then crashed, with the usual gtk
progress meter error.

Comment 54

[Akkana Peck]

Note: this is actually a little different than last time (same error, but
different place) since this time it's happening before any files are downloaded,
rather than after downloading all the files.  Unfortunately, it has already
deleted the old install, so it still leaves the user with no browser.  (Filed
bug 111077 requesting that the installer not delete the existing installation
until it's ready to install a new one; this is a problem I hit all the time and
it always means going back to 4.x or some other browser.)

Comment 55

[selmer (gone)]

Please set a new target milestone.

Comment 56

[Akkana Peck]

In a more recent build, it didn't crash, but it spewed out many many screenfuls
of Gtk warnings on the progress bar during the download phase.  

Comment 57

[Jeremy M. Dolan]

I don't see the crash anymore, either. Just truckloads of the assert issue. A
recent installer though all of Nav, PSM, and talkbalk were something like
1400k... So once a second for the other  9 meg, it printed a three line warning.
I believe there's a seperate bug on that, but it only covers talkbalk size being
calculated wrong, IIRC.

Comment 58

[Jeremy M. Dolan]

New crashes are being caused by Inspector. If it's selected, you crash towards
the end of install, and can't recover (bug 112831).

Also, bug 109053 reports "Installers after 2001110209 crash". Perhaps NT4 only.

For referrance, regarding Akkana'a exceeding 100% comment, that is bug 84492.

Once those are fixed we'll really be able to see if this one is WFM now.

Comment 59

[Syd Logan]

*** This bug has been marked as a duplicate of 122918 ***

Comment 60

[K'Trina Medina]

Verified as a dupe of bug 122918