Closed Bug 41376 Opened 24 years ago Closed 24 years ago

Error 340 during installation with NSMacInstaller

Categories

(SeaMonkey :: Installer, defect, P1)

Product:
SeaMonkey
Component:
Installer
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: agracebush, Assigned: samir_bugzilla)

Details

(Keywords: relnote, Whiteboard: [nsbeta2+][dogfood-]) 

A box with this error pops up during installation (following download or 
extraction) and pressing ok/close presents one or two more of the same error 
message.  I have not been able to reproduce at will- with a specific set of 
steps to determine what is causing-generally next attempt at installation is 
successful
Debugging reveals that intermittently NS_ERROR_FACTORY_NOT_REGISTERED 
(0x80040154L) is returned from xpistub's XPI_Init() invocation.  We are stuffing 
it into a signed int which leaves only 0x154 = 340 in decimal.  Hence, error 
340.  This error is usually returned from CreateInstance() which would indicate 
flakiness during autoreg.  Needs more investigation. 

Can't have the installer behaving flaky for nsbeta2.  Hance, nominating.
Status: NEW → ASSIGNED
Keywords: nsbeta2
Priority: P3 → P1
Target Milestone: --- → M17
Putting on beta2 plus radar: If we can't install cleanly, we'll lose lots of 
customers right out of the box :-(.
Whiteboard: [nsbeta2+]
Samir,

I am reproducing this pretty consistently - by installing 6/05 build to default 
folder, then trying to install 6/06 build on top of it- to check bug 39893- I 
should get the error message before download- that an install exists at that 
location but instead- download takes place and during extraction I get the error 
340

Grace,
Is it possible for you to reproduce this behavior by following the same steps on 
a freshly rebooted machine with an empty "Temporary Items" folder (separate from 
the one you are on)?  (I can show you how to ensure a clean "Temporary Items" 
folder.)  

If this is consistently reproducible on another system I will try to debug using 
these steps.  It would be extremely helpful to have a consistent case to help 
debug the problem.  Thanks a ton!
I get this error attempting a clean install with 060608 and 060708 Installer
mozilla bits. 
second attempt at installation works for me. 
was not able to reproduce on another system-

It's a problem.  It's inconsistent.  I'll investigate from here on.  Don't waste 
your time guys.  Thanks for the help.
This is dogfood for commercial release as far as AIM is concerned. 
If installer fails for _any_ reason, Aim won't get installed in prefs, switcher 
or task menu. 
Nominating dogfood as this prevents me from verifying any bugs regarding prefs 
or verifying anything where I need to launch IM from task menu or switcher.
cc amusil,lchiang,scalkins
Severity: normal → critical
Keywords: dogfood
Putting on [dogfood+] radar.
Whiteboard: [nsbeta2+] → [dogfood+][nsbeta2+]
I disagree with scalkins's comment, and if that is the only reason for 
dogfoodness then I appeal it back to its former nsbeta2+ status.

This error, when it occurs, happens before *anything* has installed. When it 
happens no one is testing anything. If it's happening a lot it then it would be 
dogfood, and would have been dogfood a lot sooner, but it's not in any possible 
way a source of problems that cause most of mozilla to install except for AIM 
overlays.

Your comment "If installer fails for _any_ reason, Aim won't get installed in 
prefs, switcher or task menu." is simply slandering the install code. There 
have indeed been a few SPECIFIC problems standing in the way of getting AIM 
chrome registered correctly:
 - nsChromeRegistry changed requiring overlays to be registered
 - install engine had to be able to register chrome
 - install scripts had to call the new register chrome command
 - Build process had to build correct chrome in optimized builds

Those specific problems have been addressed, and note the last took a long time 
to solve precisely because no one believed me that the installer was working 
correctly, also the attitude expressed by your comment.
Whiteboard: [dogfood+][nsbeta2+] → [nsbeta2+]
Sorry if we lumped the various parts of installing IM and having it show up
under the product all under "install".  We're just doing it from a user's
perspective and we'll try to understand how the entire process of packaging,
etc, works in the future.  As to "dogfood", my understanding is that if a bug
prevents anyone from using the product, s/he can nominate for dogfood and the
PDT team will decide.  If the PDT team needs more info as to how many people a
particular bug may affect or whether the bug is easily encountered, the team can
ask the reporter for more info.

We were apparently mistaken in this case and you were correct to let us know
that the bug may not be as serious to all users.  Now, the PDT team can re-
evaluate based on your comments for this bug as to the "dogfood" status since it
only affects the person testing IM.

Thanks.

I'm very sorry if anyone was offended by my comments. 
I did not mean to slander anyones code or imply a "bad attitude", but was only 
emphasizing from my personal QA perspective that this was indeed dogfood, 
preventing me from being able to do daily work for AIM on any build it occured 
with. My understanding from devlopment prior to nominating this dogfood was if 
there was any case where installer failed to install seamonkey, and therefore 
caused QA to uncompress the files instead of run installer to use it, Aim would 
not be present in the prefs, switcher or task menu. This did have a serious 
affect on work for me in QA for Aim since early May. 
Again, please accept my apologies as this was not intended to be taken in a mean 
spirited context, but simply stating facts as I had them presented to me in AIM 
QA up to this date.
Putting on [nsbeta2+][dogfood-]...scalkins..go see leger if this is not cool for 
ya.
Whiteboard: [nsbeta2+] → [nsbeta2+][dogfood-]
couple of comments.  This has happened to me with the last few Installer builds
I have tried.  I have cleaned out all previous moz files and tried a clean
install with 60912 (M16 branch moz bits) and got the error the first 5 times I
tried to run the installer.  On the 6th attempt it worked fine. My experience is
the same as gbush.  I get the error, hit OK and then the error pops up two more
times.  
Asa,
I have solicited Grace's help to isolate the first build in which these symptoms 
were manifested.  Can you help narrow this down too if you have cycles?  Thanks.  
This is great info.
After painstakingly working backwards with archived builds it appears that the 
problem was introduced between 05/10/2000 20:00:00 and 05/11/2000 08:00:00 
builds.  The problem appears to be with the wizard, not XPCOM even though the 
error is coming back from xpistub.  Still investigating.
I should note, since Bugscape bug 1001 was fixed, installing Mac via 
uncompressed file instead of installer still allows us to see IM in 
switcher,prefs and task menu where before it did not. This supports dveditz 
comments on  6/8
adding relnote kw for m16...
Keywords: relnote
I think I've fixed this in the M17 trunk.  (I say "I think" because you never 
know with heisenbugs.)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I have done multiple installations today with both Moz and NS installers- have 
not had one error message-build 2000061508
Status: RESOLVED → VERIFIED
I'm getting Error 340 consistently with the Netscape 6 PR2 installer (MacOS 9, 

PPP).  Isn't that based on M17?



I reported it to the Netscape 6 Feedback Center and referenced this bug.

I noticed one thing that might be a clue:  it gets the error before it succeeds 

in invoking PPP.  That is, even if the computer is offline, it makes no attempt 

to dial out (or gets an error before it gets that far).  It gets the same error 

if it's already online, though.



Online or off, it reports Error 340 twice.  It beeps once on the first alert, 

twice when it's dismissed and the second instantly comes up, and half a beep when 

that is dismissed and it exits.


I also tried deleting all files in the invisible Temporary Items folder, per Bug 
#45504.  It didn't help.

However, I just noticed that the version number (in the Mac file system) of the 
Netscaoe 6 Installer (dated August 7) is "5.0 M11".  So my understanding that 
Netscape 6PR2 was based on M17 may be mistaken, as far as the installer is 
concerned.  Looks like it may just be Netscape's problem.  But if there's any 
doubt about whether it's fixed in M17, the clue above might be of some help.

A respin of the PR2 installer is under way.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.