Closed Bug 41376 Opened 26 years ago Closed 26 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: 26 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.