Installer crashes after downloading

VERIFIED DUPLICATE of bug 122918

Status

SeaMonkey
Installer
--
blocker
VERIFIED DUPLICATE of bug 122918
17 years ago
13 years ago

People

(Reporter: Akkana Peck, Assigned: Syd Logan)

Tracking

({crash})

Trunk
mozilla0.9.7
x86
Linux
crash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], [ETA 09.27])

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
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?
Assignee: ssu → syd

Updated

17 years ago
QA Contact: gemal → ktrina
(Reporter)

Comment 2

17 years ago
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.)
(Reporter)

Comment 3

17 years ago
*** Bug 96253 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 4

17 years ago
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.
Keywords: crash

Comment 5

17 years ago
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

16 years ago
Linux installer has been completly broken TWO WEEKS. This is still untargeted.
(Assignee)

Comment 7

16 years ago
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

16 years ago
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

16 years ago
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
(Reporter)

Comment 10

16 years ago
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

16 years ago
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

16 years ago
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.
(Assignee)

Comment 13

16 years ago
<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.
Status: NEW → ASSIGNED
(Assignee)

Comment 14

16 years ago
Created attachment 48530 [details] [diff] [review]
patch, should fix the problem
(Assignee)

Comment 15

16 years ago
patch does not help, something is getting clobbered before we reach here.
(Assignee)

Comment 16

16 years ago
I can't duplicate on Chris's machine either.
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

16 years ago
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.
(Reporter)

Comment 19

16 years ago
Nominating for the branch.  It would be very sad to release a milestone that
many of us can't install ourselves.
Keywords: nsbranch
(Assignee)

Updated

16 years ago
Keywords: nsbranch → nsbranch+
Target Milestone: --- → mozilla0.9.5
(Assignee)

Comment 20

16 years ago
Created attachment 49471 [details]
Purify log from solaris
(Assignee)

Comment 21

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

Comment 22

16 years ago
Syd - What's the status on this one?
Whiteboard: PDT
(Assignee)

Comment 23

16 years ago
*** Bug 97500 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

16 years ago
*** Bug 100262 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 25

16 years ago
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

16 years ago
Pls provide the PDT with an ETA.
Whiteboard: PDT → PDT, [ETA ?]
(Assignee)

Comment 27

16 years ago
No clue on the ETA.
(Reporter)

Comment 28

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
Samir - Any ideas here?
(Assignee)

Comment 33

16 years ago
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)
(Assignee)

Comment 34

16 years ago
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

16 years ago
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.
(Assignee)

Comment 36

16 years ago
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.
(Reporter)

Comment 37

16 years ago
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.
(Assignee)

Comment 38

16 years ago
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

16 years ago
Right, the [0,1] is bug 83478.  It appears to be orthogonal to the crash.
(Assignee)

Comment 40

16 years ago
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.
(Assignee)

Comment 41

16 years ago
I've got a fix, going to do some more testing and put up a patch later tonight...
(Assignee)

Comment 42

16 years ago
*** Bug 93697 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 43

16 years ago
Created attachment 51039 [details] [diff] [review]
make sure to only CRC check files that got downloaded

Comment 44

16 years ago
r=jaggles
(Assignee)

Comment 45

16 years ago
Dauphin reports this fixes his reproducible crash. 

Comment 46

16 years ago
Let's get the sr=, and the reviews in Patch Status, so we can take this one off
the radar.
Whiteboard: PDT, [ETA ?] → [PDT], [ETA ?]
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 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
Attachment #51039 - Flags: superreview+
Attachment #51039 - Flags: review+

Comment 49

16 years ago
check it in - PDT+
Whiteboard: [PDT], [ETA ?] → [PDT+], [ETA 09.27]
(Assignee)

Comment 50

16 years ago
Fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 51

16 years ago
Grace and I could not reproduce this. Akkana, can you (or anyone that has
reproduced this) please verify this has been fixed? 
i haven't encountered either bug 97500 or a crash with recent trunk or
0.9.4-branch linux bits. marking verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 53

16 years ago
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 54

16 years ago
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

16 years ago
Please set a new target milestone.
Target Milestone: mozilla0.9.5 → ---
(Reporter)

Comment 56

16 years ago
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.  
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla0.9.7

Comment 57

16 years ago
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

16 years ago
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.
(Assignee)

Updated

16 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 59

16 years ago

*** This bug has been marked as a duplicate of 122918 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE

Comment 60

16 years ago
Verified as a dupe of bug 122918

Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.