Closed Bug 109044 Opened 23 years ago Closed 21 years ago

Install error -239 registering chrome on some systems

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: pali, Assigned: ssu0262)

References

(
URL
)

Details

(Keywords: fixed1.4.1, Whiteboard: [adt3])

Attachments

(2 files)

patch for mozilla/xpinstall/src/nsRegisterChrome.cpp
367 bytes, patch
ssu0262
: review+
dveditz
: superreview+
asa
: approval1.4.1+
Details | Diff | Splinter Review
debugging patch for mozilla/xpinstall/src/nsRegisterChrome.cpp
6.23 KB, patch
Details | Diff | Splinter Review
We are getting bug report about installation problems with latest linux nightlies on MozGest. Doen't matter if user is root or not. --mondo
Sorry I can't be more specific. Few people on #mozillazine tested this with recent nightlies on W98, worked ok. Linux guys get -239. I don't know but it looks like a linux specific issue AFAIK. --mondo
Same linux testers report that thay have no problem to install jabberzilla nor hermes. Here is our content.rdf: <?xml version="1.0"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> <RDF:Seq about="urn:mozilla:package:root"> <RDF:li resource="urn:mozilla:package:mozgest"/> </RDF:Seq> <RDF:Description about="urn:mozilla:package:mozgest" chrome:displayName="Mouse Gestures" chrome:author="Andy Edmonds" chrome:name="mozgest"> </RDF:Description> <RDF:Seq about="urn:mozilla:overlays"> <RDF:li resource="chrome://navigator/content/navigator.xul"/> <RDF:li resource="chrome://communicator/content/pref/preftree.xul"/> </RDF:Seq> <RDF:Seq about="chrome://navigator/content/navigator.xul"> <RDF:li>chrome://mozgest/content/mozgestOverlay.xul</RDF:li> </RDF:Seq> <RDF:Seq about="chrome://communicator/content/pref/preftree.xul"> <RDF:li>chrome://mozgest/content/pref/mozgestPrefOverlay.xul</RDF:li> </RDF:Seq> </RDF:RDF>
Reassigning QA Contact to Grace. See if you can reproduce this problem. -239 is CHROME_REGISTRY_ERROR
QA Contact: jimmylee → gbush
cannot reproduce this with Mozilla nightly build 2001110908 nor commercial trunk build 2001110908 package loads without errors and when relaunch- Mouse gestures are working
I still confirm this bug on build 2001110908 linux 2.2 (Window Maker) I cc'ed folks that experienced the same problem (Mozdev-bug 663) What can we do to help you to investigate this problem?
duplicate of bug 29741?
I don't think so. I tried to install mozgest as root (thus with write privileges) and the reported error is -239, not -225.
We have this confirmed on Solaris. See our mozdev bugzilla: http://mozdev.org/bugs/show_bug.cgi?id=663
I've seen this bug for a number of weeks (at least) under linux nightly builds, both with mouse gestures and with (total) recall, another mozdev project. Still in build 2001110815. There was talk that this was related to only builds compiled by mozilla.org (IIRC), with reports of success if mozilla was built from source.
Just to confirm that this is still present in 2002011021 (linux).
andrea says that this bug blocks localization. Are all xpi's on linux are broken? I tried installing the above url and it gave me the download dialog but didn't download anything. Pressing cancel did nothing. (using 2002012909, 0.9.8 branch)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm able to install everything I've tried one time. Some of the XPI's failed when I attempted a second install of the same XPI (like optimoz and the brfr 0.9.7 localization XPI). I get an error -215.
I had reports about describing this behaviour, but now I've tested on 098 build 2002-01-30 and the bug seems gone. The Chinese-China 097 lang pack still shows this behaviour, but its fault of the installation script. (I'll fix it) I've tested the optimoz 0.3.2 xpi and it works ok. I've also tried to start the 0.3 xpi download and the installation dialog triggers correctly. Everything clear with this build for me. If anyone still find incriminated xpi, please let me know (I'll try to take a look). Thank you all.
Erase and rewind :) Now I've tested the 0.9.7 release again (build 2001122108 on tar.gz). At home with a SuSE 7.1 distro it gives me a straight -239 with any lp. This is also reproduces with another Italian reporter with a SuSE 7.2. Then I've tested 097 on a Red Hat 6.7 at Univ. It returns a -204 (= no install script !!) stopping immediatly the xpi installation as reported by Dawn Endico. Testing again the same mozilla installation, from the same folder, logged as the same user, again with Red Hat 6.2 installed on the machine used for the test of my previous comments ( #13 ), the installation succeed, and I can see with no problems Italian, German or whatever. I think it might be a problems with libs. I just decompress mozilla into a folder (I have all the rights on it) and add the executables folder to my $PATH variable. Any hint ?
Status: NEW → ASSIGNED
*** Bug 124809 has been marked as a duplicate of this bug. ***
I am seeing this when with release 0.9.8 (2002020415/linux), when I try to install a language pack or the uabar. The odd thing is that no error dialog is shown, so the user restarts mozilla just to wonder why nothing has changed. Is there a seperate bug for at least showing an error message in case something goes wrong with install?
Originally we were told web designers wanted to control the experience, so the error status is reported to the launching page via a callback. In practice, however, more sites provide simple links and don't register the callback. bug 98458 covers adding error display to the standard UI.
nominating, the flakiness of this problem introduces significant risk to MachV.
Keywords: nsbeta1
required comment
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.9
syd: Wich kind of comments do you need ? How can I help you ?
same problem bug 106701?
Arrgh. It really seems to be a duplicate of bug 106701. I'm gonna leave it as a standalone bug waiting for comments from others (and because I probably have not enough Bugzilla rights).
*** Bug 106701 has been marked as a duplicate of this bug. ***
handing to bryner since I strongly suspect a tie to bug 126113. When XPInstall reports a -239 it means the chrome registry command failed. Since the same package works on some machines (usually older ones) and not others I think the chrome registry itself is the culprit. There are differences from bug 126113, though, so I don't think it's a straight duplicate. In that one the chrome is installed using the DELAYED_CHROME style (like bug 106701) meaning through the installed-chrome.txt file, and the failure is to write out the overlayinfo. In this we're trying to use the chrome registry install() method and getting an error code.
Assignee: syd → bryner
Status: ASSIGNED → NEW
Summary: Error -239 on recent linux nightlies → Install error -239 registering chrome on newer Linux kernels
I'm citing inline the install.log tested with the 2002030106 build under SuSE 7.1 I've used the 098 Italian lang pack you can find at ftp://ftp.mozilla.org/pub/mozilla/l10n/lang/moz098/ The 2nd installation is referred to the very same package with the DELAYED_CHROME flag. ------------------------------------------------------------------------------- file:///home/Andrea/langitit.xpi -- 03/02/2002 00:48:50 ------------------------------------------------------------------------------- ** initInstall: platformNode=unix Italian (it-IT) Language Pack ----------------------------- ** initInstall: 0 ** Base installation folder: /home/Andrea/moz099/ ** addDirectory() returned: 0 [1/37] Installing: /home/Andrea/moz099/defaults/profile/IT/mimeTypes.rdf [2/37] Installing: /home/Andrea/moz099/defaults/profile/IT/bookmarks.html [3/37] Installing: /home/Andrea/moz099/chrome/IT.jar [4/37] Installing: /home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userChrome.css [5/37] Installing: /home/Andrea/moz099/chrome/it-IT.jar [6/37] Installing: /home/Andrea/moz099/defaults/profile/IT/search.rdf [7/37] Installing: /home/Andrea/moz099/chrome/it-unix.jar [8/37] Installing: /home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userContent.css [9/37] Installing: /home/Andrea/moz099/defaults/profile/IT/localstore.rdf [10/37] Installing: /home/Andrea/moz099/defaults/profile/IT/panels.rdf [11/37] Installing: /home/Andrea/moz099/chrome/it-win.jar [12/37] Installing: /home/Andrea/moz099/chrome/it-mac.jar [13/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/communicator/ Install **FAILED** with error -239 Install **FAILED** with error -239 ** performInstall() returned: -239 Finished Installation 03/02/2002 00:48:52 ------------------------------------------------------------------------------- file:///home/Andrea/ititdelayed.xpi -- 03/02/2002 00:49:24 ------------------------------------------------------------------------------- ** initInstall: platformNode=unix Italian (it-IT) Language Pack ----------------------------- ** initInstall: 0 ** Base installation folder: /home/Andrea/moz099/ ** addDirectory() returned: 0 [1/37] Installing: /home/Andrea/moz099/defaults/profile/IT/mimeTypes.rdf [2/37] Installing: /home/Andrea/moz099/defaults/profile/IT/bookmarks.html [3/37] Installing: /home/Andrea/moz099/chrome/IT.jar [4/37] Installing: /home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userChrome.css [5/37] Installing: /home/Andrea/moz099/chrome/it-IT.jar [6/37] Installing: /home/Andrea/moz099/defaults/profile/IT/search.rdf [7/37] Installing: /home/Andrea/moz099/chrome/it-unix.jar [8/37] Installing: /home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userContent.css [9/37] Installing: /home/Andrea/moz099/defaults/profile/IT/localstore.rdf [10/37] Installing: /home/Andrea/moz099/defaults/profile/IT/panels.rdf [11/37] Installing: /home/Andrea/moz099/chrome/it-win.jar [12/37] Installing: /home/Andrea/moz099/chrome/it-mac.jar [13/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/communicator/ [14/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/content-packs/ [15/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/cookie/ [16/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/editor/ [17/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/global/ [18/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/messenger-mapi/ [19/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/messenger-smime/ [20/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/messenger/ [21/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/mozldap/ [22/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/navigator/ [23/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/necko/ [24/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/pipnss/ [25/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/pippki/ [26/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/wallet/ [27/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/chatzilla/ [28/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/inspector/ [29/37] Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/venkman/ [30/37] Register Locale: jar:resource:/chrome/it-unix.jar!/locale/it-IT/global-platform/ [31/37] Register Locale: jar:resource:/chrome/it-unix.jar!/locale/it-IT/communicator-platform/ [32/37] Register Locale: jar:resource:/chrome/it-unix.jar!/locale/it-IT/navigator-platform/ [33/37] Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/communicator-region/ [34/37] Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/editor-region/ [35/37] Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/global-region/ [36/37] Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/messenger-region/ [37/37] Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/navigator-region/ Install completed successfully ** performInstall() returned: 0 Finished Installation 03/02/2002 00:49:27
I'm really not convinced that 'newer linux kernels' is appropriate, assuming its normal meaning. I get failure here with, currently, 2002022208 linux nightly, under a system with a 2.0.36 kernel and debian testing/unstable!
fair enough. It's still a mystery what's actually causing the problem.
Summary: Install error -239 registering chrome on newer Linux kernels → Install error -239 registering chrome on some systems
not going to make 0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Whiteboard: [adt3]
No longer blocks: 115520
dveditz, do you think you could take this? I doubt I'm going to be able to make any progress on it.
Damn, you win the "most doomed" contest 10 to 7 (nsbeta1+). <sigh> I have no idea where to begin :-(
Assignee: bryner → dveditz
I looked for whether to solve this problem. Therefor I incompetently changed: diff install.js 1/install.js: 44c44 < registerChrome(Install.CONTENT , getFolder(mgDir, "content")); --- > registerChrome(5 , getFolder(mgDir, "content")); Now it works! The value of Install.CONTENT is 4.
This has helped our XPI installer, though it is IMHO just a workaround... We changed our install script to registerChrome(CONTENT | DELAYED_CHROME, getFolder(mgDir, "content")); instead of registerChrome(CONTENT , getFolder(mgDir, "content")); Users report that installation works for them. --mondo
*** Bug 136981 has been marked as a duplicate of this bug. ***
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
*** Bug 140662 has been marked as a duplicate of this bug. ***
*** Bug 140949 has been marked as a duplicate of this bug. ***
*** Bug 111898 has been marked as a duplicate of this bug. ***
Can you do anything with this information: http://multizilla.mozdev.org/xpi/linux-inst-error.txt ?
Don't know if this is just a personal impression, but the -239 problem is found always when mozilla is installed from an RPM. Or at least installing moz from the RPM distribution makes things go wrong (so I can't say if this another bug). Probably in bug 140949, this is the case.
Andrea: from my findings, it happens on almost any unix install when installing without DELAYED_CHROME set. The real problem for L10n is, that we need to use DELAYED_CHROME because of this bug for unix installs, and DELAYED_CHROME does not work with profile installs, as it just adds the right lines to installed-chrome.txt so that they're read and 'executed' on the following restart of Mozilla. This means, that because of this bug 1) every unix user needs to have write permissions on the mozilla directory to install an additional language pack 2) the user has to restart mozilla to even see the newly installed package in preferences dialog (another restart is needed for actual switching) 3) this sometimes fails, as - for unknown reasons - there are some cases where installed-chrome.txt isn't parsed correctly at restart, the user has to delete chrome.rdf in this case, then everything works Because of that, this is really annoying for L10n people. The problem is, nobody seems to know why this is happening... :((
This bug remains on 1.0RC3. I think this bug should be fixed or we'd have problem spreading Mozilla 1.0 Release over the world due to the L10N problem.
Hugh-teh: can you confirm this bug on RC3? Did you tested _without_ the DELAYED_CHROME switch while logged either as user or while logged as root?
While I'm still trying to understand if this bug is defenitely gone on linux, the l10n Traditional Chinese (Taiwan) contributor has repoted to me the impossibility to install a lang pack either with or without the DELAYED_CHROME switch while installing: logged as user on a Free BSD system from the latest-1.0 build. Could someone add in the CC of this bug someone who could deal with the *BSD tree? I wonder if something (good) has happen in the meanwhile on the linux builds, has not been reflected on other trees (like BSD).
Pete is a BSD person (see last comment)
There are some file issues on Asian systems that apparently started in 1.0rc3 and will hopefully be fixed in 1.0.1 -- I'm guessing that's the root of the problems your Chinese translator found, although it's just a guess. See bug 147333
Disclaimer: I develope software but not for Mozilla (at the present;)... I have played around with BannerBlind: http://bannerblind.mozdev.org/installation.html and ran across this bug. A little research has shown what the real bug is (for my system at least, under Debian): It's permission denied in altering the chrome files. I'm running debian unstable and Mozilla 1.0 and I was recieving the -225 error (permission denied, though it never told me where, darn it). I fixed this by doing: cd /usr/lib/mozilla sudo chgrp -R staff . ; sudo chmod -R g+rwX . ; sudo find -type d -exec chmod g+s {} \; After doing this, I got the -239 error. I looked around and saw that component.reg was a symlink to /var/lib/mozilla/component.reg I repeated my commands in /var/lib/mozilla and then I was able to successfully install the .xpi. There are three things that bug me about this: 1) The error messages were singularly unhelpful. After I changed the permissions in /usr/lib/mozilla I finally got a *little* more info from /usr/lib/mozilla/install.log (which I would never had looked at): Install **FAILED** with error -239 -- 07/31/2002 13:37:23 2) The errors are obviously not passing up from the chrome component. 3) And last, but not least by a long shot: It shouldn't be installing this stuff to /usr/lib anyway! I have a whole $HOME directory for this stuff, for goodness sake, use it! Anyway, I suspect things like the symlink to /var and stuff might be why this wouldn't work for RPMs and such, since the FHS would require the chrome stuff to go in var. Though, as I mention, this stuff should all go in the HOME directory, unless root does an install and checks a check box saying "Yeah, I want this system wide". Otherwise, use $HOME! Anyway, hope this helps. Ciao!
Blocks: 164804
This bug still exists on at least FreeBSD for recent nightly builds. (and 1.2a release) dveditz@netscape.com mentioned about bug 147333 (see comments above), but that's about loading local files with non-ASCII filenames. I did not put any non-ASCII characters in the language pack. So I guess it is not the reason to this bug...
Christian, check the install.js of the package you're trying to install. It is it which states if chrome should try to install the package in $HOME or not.
The normal file permission problem some of the reporters refer to truly is an easy one to run into on unix systems. Especially when xpi doesn't report it's intent to install itself system-wide or when user doesn't even know what that means. Projects like http://www.debian.org/devel/debian-desktop/ try to remedy these situations, but the installation dialog could still be a tad more expressive, mention the install.log file for example.
Samuli Tuomola: The file permission problem is not what this bug is really about. Comment #25 describes the problem really good. We don't fail when copying files into the Mozilla directory, and we don't fail adding entries to installed-chrome.txt (using DELAYED_CHROME), neither do we fail when registring the (new) entries of installed-chrome.txt on a restart. What we do fail with, is registering the components with the chrome registry directly. No one's really sure why this happens. The real downside: It still blocks us from being able to install langpacks to the profile on unix, that's sure, and it makes unix users need an additional restart of Mozilla when installing a langpack. It was targeted for 1.0, that target was failed by far. We really would need someone who can track the problem down to where it really happens, then people would more easily be able to fix it. I'd be willing to provide a German langpack without our DELAYED_CHROME workaround enabled, so that it should really hit the bug, given that someone will need it for testing.
Hmm, magic happens sometimes: I just realized that DELAYED_CHROME has stopped working on 1.3/Linux (It still worked on 1.3b), and so I thought I'll dare to do a standard install. The interesting part comes now: It worked, and even a profile install worked! I now released the German 1.3 XPI pack that way, it will be interesting if someone will start to complain about this bug again. Actually, some changes between 1.3b and 1.3 final seem to have broken DELAYED_CHROME but that bug seems to be magically fixed here - but I won't believe it until it works for more people... So please, try all your testcases etc. with 1.3 and current nightlies, let's see if it still happens!
I believe I found one reason why this could be happening: If I'm taking things correctly, we spit out an error -239 if we try to register a currently used chrome registry entry again in chrome registry and probably want to change that entry. I'm not sure if this might be the real case, but I tried to re-install a locale pack today on a build that had already installed that pack, and it failed when trying to register the communicator package...
-> Sean
Assignee: dveditz → ssu
some people upgrading Linky are getting this error: http://mozdev.org/bugs/show_bug.cgi?id=3823 http://www.mozillazine.org/forums/viewtopic.php?p=89030#89030 any chance that XPI Install could get more debug info?
To add to comment 55, the -239 chrome error when upgrading from one version of Linky to another (1.7.0) has been happening not *just* on *nix, but under Win32 as well. From MozillaZine: http://www.mozillazine.org/forums/viewtopic.php?p=89030#89030
this is bad... very bad. this one should be fixed.
OS: Linux → All
I can't reproduce this bug on winXP or RH8.0 with the linky tool. I've tried upgrading and also installing the same version. All works fine. Will try a few other test scenarios. I did find that if I only had read permissions to .../chrome/installed-chrome.txt, it would die with -239. The install.log looks exactly like the one in comment #25.
I can reproduce this reliably on Firebird nightlies (Gecko/20030702 Mozilla Firebird/0.6) installing the Linky extension. Anyone wanting further info or debug to track it down mail me instructions and I'll send you any info you need...
The problem with linky seems to be that it is trying to register a non-existent locale. I don't have the locale "da-dk" setup on my system. So, I changed the line: const myLocales = new Array("en-US", "da-dk"); // the locales available to const myLocales = new Array("en-US"); // the locales available and the install worked. (The script later does this: for (var i = 0; i < myLocales.length; i++) { err_tmp = registerChrome(LOCALE | PROFILE_CHROME, sysChromeUserJar, "locale/" + myLocales[i] + "/" + myProductRegKey + "/"); } ) I'm also not certain that "da-dk" is valid. Shouldn't it be "da-DK"? ------------------------------------------------------------------------------- file:///M:/tmp/linky/linky.xpi -- 07/10/2003 10:44:16 ------------------------------------------------------------------------------- Linky (version 1.7.1.20030602) ----- ** Linky version 1.7.1 being installed on 2003062408 ** Installation method is 2 ** ok adding jar file. ** ok registering the content chrome. ** ok registering the locale chrome. [1/4] Replacing: E:\Documents and Settings\GCoakley\Application Data\Mozilla\Profiles\default\lr5x4i5v.slt\chrome\linky.jar [2/4] Register Package: jar:file:///E:/Documents%20and%20Settings/GCoakley/Application%20Data/Mozilla/Profiles/default/lr5x4i5v.slt/chrome/linky.jar!/content/linky/ [3/4] Register Locale: jar:file:///E:/Documents%20and%20Settings/GCoakley/Application%20Data/Mozilla/Profiles/default/lr5x4i5v.slt/chrome/linky.jar!/locale/en-US/linky/ [4/4] Register Locale: jar:file:///E:/Documents%20and%20Settings/GCoakley/Application%20Data/Mozilla/Profiles/default/lr5x4i5v.slt/chrome/linky.jar!/locale/da-dk/linky/ ** Problem performing install. Error code: -239 ** Problem installing. Error code: -239. Error codes can been seen at: http://devedge.netscape.com/library/manuals/2001/xpinstall/1.0/err.html Install **FAILED** with error -239 -- 07/10/2003 10:44:31
Removing "da-dk" from that array does the trick for me too, with Firebird 0.6. (Thanks.)
Just tried to install locally (in-profile) and it worked after I changed da-dk to da-DK. It seems the parser may be missing a call to or two to tolower() or equivalent. I'm sure locale names should be case-insensitive. (or are they?)
This is happening on FreeBSD with: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5a) Gecko/20030731 Mozilla Firebird/0.6.1 The strange thing is, I have the same browser (built from the ports collection) at home, and there the AdBlock install _was_ successful. Also, the .jar file is not actually placed anywhere. ------------------------------------------------------------------------------- http://adblock.mozdev.org/adblock-firebird-0.3.xpi -- 08/04/2003 10:58:28 ------------------------------------------------------------------------------- AdBlock (version 0.3) ------- [1/2] Installing: /usr/home/drwilco/.phoenix/default/xybwlyf0.slt/chro me/adblock.jar [2/2] Register Content: jar:file:///usr/home/drwilco/.phoenix/default/ xybwlyf0.slt/chrome/adblock.jar!/content/ Install **FAILED** with error -239 -- 08/04/2003 10:58:29
This fixed the unexplainable -239 error when installing the AdBlock extension. Lines 247 - 254 depend on NS_SUCCEEDED(rv) being true before entering that block, but rv is not initialized to anything before there.
Attachment #129229 - Flags: review?(ssu)
Comment on attachment 129229 [details] [diff] [review] patch for mozilla/xpinstall/src/nsRegisterChrome.cpp r=ssu great job DocWilco! Here are DocWilco's comments on how he figured this out: ======================================= Yes this patch fixed the problem for me at work. It was a tough one to crack, because at home I didn't have the problem at all. But diff version of FreeBSD and diff version of GCC might have something to do with that. I started out adding fprintf()s everywhere where CHROME_REGISTER_ERROR (or whatever the define for 239 was) was used. Adding them with else blocks to all the if's. That did make it any clearer, so I then added "if(NS_FAILED(rv)) fprintf("bla %d %s", __LINE__, __FILE__);" right after any use of rv that might change its value. That showed me that rv contained an error on line 249 already, and after adding debug fprintf()s in the chrome lib I found out that InstallSkin on line 428 wasn't even called. So rv contained an error, even though it hadn't been assigned any value yet. Causing the if statements on 250 and 253 to short circuit. Setting rv to NS_OK at the declaration did indeed fix that, and AdBlock stopped failing to install (and I'm using it on that machine with success). I can't see how my change would have a negative impact either, since it makes good on the assumption that's made on lines 250 and 253.
Attachment #129229 - Flags: superreview?(dveditz+bmo)
Attachment #129229 - Flags: review?(ssu)
Attachment #129229 - Flags: review+
Sean: could you also check it in, since I dont have cvs access
sure, I can check it in once all the reviews are done.
Status: NEW → ASSIGNED
Comment on attachment 129229 [details] [diff] [review] patch for mozilla/xpinstall/src/nsRegisterChrome.cpp sr=dveditz We should consider this simple and safe fix for 1.4.1
Attachment #129229 - Flags: superreview?(dveditz+bmo)
Attachment #129229 - Flags: superreview+
Attachment #129229 - Flags: approval1.4.x?
patch checked in to trunk only. Thanks DocWilco for the patch!
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment on attachment 129229 [details] [diff] [review] patch for mozilla/xpinstall/src/nsRegisterChrome.cpp a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #129229 - Flags: approval1.4.x? → approval1.4.x+
patch checked in to MOZILLA_1_4_BRANCH.
Keywords: fixed1.4
Keywords: fixed1.4 → fixed1.4.1
I just got this error again using Firebird 8/16 under XP trying to install Linky 1.7.1. I need to either reopen the Linky bug (http://mozdev.org/bugs/show_bug.cgi?id=3823) or this bug, depending on if it's a browser bug or a Linky bug. Opinions?
Confirming that it is (was) definitely Linky's fault, not this bug. The latest version (2.0.0) works just fine without a -239 error.
Even with Linky 2.0.0 I've seen the -239. I'm currently not able to reproduce, but I'll open a new bug if I can found out why. So it's not 100% Linky's fault.
Do you install addons in your profile directory or globally? Is this triggered by installing addons in your profile directory, after you've first installed it globally or vice versa?
I cant really remember. I just got -239 every time I tried to install. I'll have to investigate
Not a patch meant for the trunk, but for people trying to figure out why they're getting a -239. It will help narrow things down a little with some extra output in install.log. When I have a little time I will improve it some (there's plenty of room for it).
that patch would be great to check in. Generating the -239 is very difficult. So checking in a patch like this would be great. please open a bug and attach the bug and let's see if we can get a r=, sr= and checkin. Please CC me on the new bug.
I opened a new bug. See bug 221994
Blocks: 224532
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: