Closed Bug 43272 Opened 25 years ago Closed 25 years ago

XPInstall fails on Japanese OS, Error -229

Categories

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

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
x86
Windows 95
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: a-mutsu, Assigned: ftang)

References

Details

(Whiteboard: [dogfood+][nsbeta2+]fix in hand, need code review)

Build 2000061311(M16)/Win32 and 2000062008/Win32 on Win95-J Installation of PSM displays an error. XPInstall Results PSM: Error encountered -- -229 Nothing is recorded by the Seamonkey/Uninstall/install1.log
Reproducible in WinNT and Linux.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 95 → All
Hardware: PC → All
Target Milestone: --- → M17
Version: 1.1 → 1.2
sorry. Is this problem a duplicate of Bug 37085 ??
Adding keyword dogfood
Keywords: dogfood, nsbeta2
Severity: critical → blocker
Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix to make a call on this bug. We need to know if the PSM is installed or not.
Whiteboard: [NEED INFO]
*** Bug 43477 has been marked as a duplicate of this bug. ***
We have not changed anything in our install script. So this is a regression either XP install or some JavaScript related bug within Mozilla.
Reassigning hopefully to the right product and person.
Assignee: ddrinan → mstoltz
Component: Client Library → Javascript Engine
Product: PSM → Browser
Version: 1.2 → other
Adding smoketest keyword. It is impossible to test SSL and wallet operations without this feature.
Keywords: smoketest
so just to confirm, this is happening on non-japanese OSes (NT and Linux) with the most recent builds?
Yes
I'm not seeing this on my NT 4.0sp6 system running today's (2000062309) build. PSM installs and I can access https: pages and click on the lock to see PSM.`
after talking with junruh, this error is occurring when installing PSM off the iplanet page into a mozilla build. I was not seeing this when installing a Netscape commercial build.
dveditz was explaining to me yesterday a problem that JS could no longer call modal dialogs, thus preventing even us from calling them (separate bug on that issue). That in turn broke XPInstall. I don't know if this could be related, I'll let him explain further.
I can confirm (from stepping through code) that the wrong things seem to happen when XPInstall opens a model dialog to confirm the installation request. The two bugs may, in fact, be related. Is the bug fixed yet? (I'm building an updated client now)
I may not be doing this right, but when I install today's mozilla build on my NT 4.0sp6 system and then go to iplanet and install the PSM, I get an error -210.
I am seeing this in both Commercial and Mozilla builds from around 9AM PDT this morning. (The error I see is -210, not -229.)
I was seeing this error yesterday evening. I called Terry Hayes and he finally gave me a zip file that I had to manually install in order to use PSM functions.
this may end up being a dupe of 43354 which is based on the inability to put up a modal dialog. if so i'm currently working on the problem. eta for a fix is sometime this afternoon.
This (seemingly?) won't block commercial tree (which uses a different installer), and hence is nsbeta2-. Developers who build the entire system don't need the installer, and hence this is dogfood- However... we'll be really glad to see outside developers contribute a fix RSN.
Whiteboard: [NEED INFO] → [dogfood-][nsbeta2-]
this is not true. developers who build the entire system *DO* need to install PSM from these xpi files. PSM is not part of the commercial build process (except possibly on mac).
Whiteboard: [dogfood-][nsbeta2-]
Since this seems to work for me now that bug 43354 is fixed I assert this was indeed a dupe. *** This bug has been marked as a duplicate of 43354 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Verified fixed.
Status: RESOLVED → VERIFIED
Was this solved? Me 2000062914/Win32 (ZIP/installer) was tried. However, it has not solved. It is the same as that of the situation reported first. Nothing is recorded by Uninstall/install1.log Build 2000062914/Win32 on Win95-J XPInstall Results PSM: Error encountered -- -229
This is NOT a duplicate of 43354 which was a dialog problem. This one is a script abort on a Japanese Win OS. I highly doubt anyone verified this bug on that platforms.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Reassigning to ssu for now, but we probably need i18n help on this. There are potentially extremely icky things in this script. The MS "Common Files" directory most likely has Japanese characters in it, so trying to create a file:// URL with those raw (un-escaped) characters is probably wrong. And then we're likely losing characters in the automatic unicode->singlebyte translation that often happens at the javascript boundary if you're not careful. For one thing we should think about adding getFolder() targets for "Win Common Files" and "Win Program Files" because these are going to be common targets, and on non-English systems pretty hard for script authors to get right.
Assignee: mstoltz → ssu
Status: REOPENED → NEW
Note I don't *know* any of the above is the problem, just guessing in a vacuum since there was no line indication for the script failure.
OS: All → Windows 95
Hardware: All → PC
I was able to install PSM on both Linux and NT using 6/29 builds.
Does this prevent the installation of PSM through the commercial installer on Japanese machines?
QA Contact: junruh → teruko
Whiteboard: [NEED INFO]
Removing smoketest blocking status, that was bug 37085. This one appears to be limited to Japanese OS, or maybe non-Enlish in general. Need teruko to investigate in the i18n lab. Is this error limited to the iPlanet PSM install, or does the Commercial install on a Japanese OS suffer as well? Once that is established, do other non-English versions of Windows have the problem, specifically those with non-ASCII characters in the install path?
Keywords: smoketest
Summary: XPInstall Results PSM: Error encountered -- -229 → PSM Install on Japanese OS: Error encountered -229
I couldn't find Teruko, so I did a quick test of my own. Running from a Win95J system: 1) install today's netscape 6 (commercial) build using the Typical setting which also installs a psm.xpi. No errors reported. 2) using the above installed build, trigger the psm from the iplanet site: http://docs.iplanet.com/docs/manuals/psm/psm-mozilla/ The Psm installer failed with a -229 error. 3) using the above installed build, go to: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-06-30-09-M17/xpi and double click on the psm.xpi file. It fails with a -229 error. 4) using the above installed build, go to: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-06-30-09-M17/upd ate.html Select only the Spell Checker component, and click the Launch XPInstall button. It fails with a -229 error. 5) installed today's commercial build on a Win95 english system and did step 4). No errors reported. It looks like it might be a general Win95J problem. Teruko, can you try the above tests on other non english systems?
This appears to be some basic problem with the XPInstall engine running on a Japanese (and possibly other non-English) Windows OS. We need to get a debuggable system on such an OS but the install team doesn't have one. Reasigning to ftang for help.
Assignee: ssu → ftang
Component: Javascript Engine → Installer: XPInstall Engine
Summary: PSM Install on Japanese OS: Error encountered -229 → XPInstall fails on Japanese OS, Error -229
I heard from one person of a community of Japan. It fails in Japanese NT4 SP5 similarly. Me Since it does not have NT, it cannot try.
This bug is appeard on my machine, WinNT4.0J/SP5. Below are traces when I launched by 'mozilla.exe -console'. Does it have any information for investigation? If it does, Please compare with English OS's traces. BuildID:20000070220 ------ Document http://docs.iplanet.com/docs/manuals/psm/psm-mozilla/ loaded successful ly WEBSHELL+ = 8 Adding element 0 : _blank WEBSHELL- = 7 WEBSHELL+ = 8 2 Adding Progress element 0 : _blank WEBSHELL+ = 9 WEBSHELL+ = 10 WEBSHELL+ = 11 Setting content window *** Pulling out the charset in SetSecurityButton WEBSHELL+ = 12 WEBSHELL+ = 13 It's NOT UTF-16BE- byte 28(1c) Setting content window *** Pulling out the charset in SetSecurityButton WEBSHELL+ = 14 It's NOT UTF-16BE- byte 28(1c) WEBSHELL- = 13 ----------
And more, XPInstall of Swedish (sv-SE) language pack is succeeded on Japanese Windows OS. in http://www.mozilla.org/projects/intl/xul-how2l10n.html
Putting on [dogfood+][nsbeta2+] radar.
Whiteboard: [NEED INFO] → [dogfood+][nsbeta2+]
accept for now.
Status: NEW → ASSIGNED
the files you want to looking into with a debugger are: mozilla/xpinstall/src/nsJSInstall.cpp mozilla/xpinstall/src/nsInstall.cpp mozilla/xpinstall/src/nsInstallFile.cpp The function you want to probably step into is: nsInstallFile::Prepare() nsInstallFile::Complete()
reassign to cata
Assignee: ftang → cata
Status: ASSIGNED → NEW
reassign back to ftang
Assignee: cata → ftang
mark it as assign
Status: NEW → ASSIGNED
here is what I got if I click on psm.xpi "Netscape Personal Security Manager" "Store Registry Value Stri...\Main [Install Directory]
I then get assertion NTDLL! 77f662ac() nsDebug::Assertion(const char * 0x011dd9bc ??_C@_0BG@EIKL@?$HMCharAt?$HM?5out?9of?9range?$AA@, const char * 0x011dd9d8 ??_C@_0BA@OBAB@aIndex?$DMLength?$CI?$CJ?$AA@, const char * 0x011dd9ec ??_C@_0CH@IHJC@?4?4?2?4?4?2dist?2include?2nsAReadableSt@, int 0x00000220) line 246 + 13 bytes basic_nsAReadableString<unsigned short>::CharAt(unsigned int 0xffffffff) line 544 + 42 bytes basic_nsAReadableString<unsigned short>::Last() line 572 nsWinProfile::nsWinProfile(nsInstall * 0x0494fb80, const nsString & {...}, const nsString & {...}) line 40 + 10 bytes nsInstall::GetWinProfile(const nsString & {...}, const nsString & {...}, JSContext * 0x04926950, JSClass * 0x011e3978 struct JSClass WinProfileClass, long * 0x04abf530) line 1103 + 39 bytes InstallGetWinProfile(JSContext * 0x04926950, JSObject * 0x03945af8, unsigned int 0x00000002, long * 0x039e537c, long * 0x04abf530) line 1259 + 35 bytes js_Invoke(JSContext * 0x04926950, unsigned int 0x00000002, unsigned int 0x00000000) line 716 + 23 bytes js_Interpret(JSContext * 0x04926950, long * 0x04abff20) line 2520 + 15 bytes js_Execute(JSContext * 0x04926950, JSObject * 0x03945af8, JSScript * 0x0496f5c0, JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0x00000000, long * 0x04abff20) line 887 + 13 bytes JS_EvaluateUCScriptForPrincipals(JSContext * 0x04926950, JSObject * 0x03945af8, JSPrincipals * 0x00000000, const unsigned short * 0x039db838, unsigned int 0x00001496, const char * 0x00000000, unsigned int 0x00000000, long * 0x04abff20) line 2768 + 27 bytes JS_EvaluateUCScript(JSContext * 0x04926950, JSObject * 0x03945af8, const unsigned short * 0x039db838, unsigned int 0x00001496, const char * 0x00000000, unsigned int 0x00000000, long * 0x04abff20) line 2750 + 35 bytes JS_EvaluateScript(JSContext * 0x04926950, JSObject * 0x03945af8, const char * 0x039da360, unsigned int 0x00001496, const char * 0x00000000, unsigned int 0x00000000, long * 0x04abff20) line 2717 + 33 bytes RunInstallOnThread(void * 0x04929170) line 426 + 30 bytes _PR_NativeRunThread(void * 0x0492ad80) line 399 + 13 bytes _threadstartex(void * 0x0492aa40) line 212 + 13 bytes KERNEL32! 77ed4f05() What happen is we try to exam the charAt[-1] from the following code mFilename->Last() since the length of mFilename is 0, Last() make it refer to -1 nsWinProfile::nsWinProfile( nsInstall* suObj, const nsString& folder, const nsString& file ) { MOZ_COUNT_CTOR(nsWinProfile); mFilename = new nsString(folder); if (mFilename) { if(mFilename->Last() != '\\') { mFilename->AppendWithConversion("\\"); } mFilename->Append(file); mInstallObject = suObj; } } The reason we refer to CharAt(-1) is because the following code, the Length() is 0 template <class CharT>inline CharT basic_nsAReadableString<CharT>::Last() const { return CharAt(Length()-1); } Also, if I look at the following frame: At nsInstall::GetWinProfile(const nsString & {...}, const nsString & {...}, JSContext * 0x04926950, JSClass * 0x011e3978 struct JSClass WinProfileClass, long * 0x04abf530) line 1103 + 39 bytes : - aFile {...} + basic_nsAWritableString<unsigned short> {...} - nsStr {...} mLength 0x0000000c mCapacity 0x0000003f mCharSize eTwoByte mOwnsBuffer 0x00000000 + mStr 0x04abf368 "r" - mUStr 0x04abf368 "ren8dot3.ini" 0x0072 - aFolder {...} + basic_nsAWritableString<unsigned short> {...} - nsStr {...} mLength 0x00000000 mCapacity 0x0000003f mCharSize eTwoByte mOwnsBuffer 0x00000000 + mStr 0x04abf400 "" - mUStr 0x04abf400 "" 0x0000 Notice aFolder = "" ( and aFile = "ren8dot3.ini" ) . The aFolder="" cause the assertion.
I am not 100% sure the assertion cause the failed. But the assertion is caused by http://lxr.mcom.com/commercial/source/xpinstall/packager/shrimp/windows/psm.jst#29 25 function updatePrivateProfile() 26 { 27 fTemp = getFolder("Temporary"); 28 fProgram = getFolder("Program"); 29 fRen8dot3Ini = getWinProfile(fTemp, "ren8dot3.ini"); somehow the fTemp is ""
I am using NT4J. I didn't see -229 yet. I get assertion (as stated above) and them a lot of thread safe assertion if I continue. I am not sure I experience the same problem as this bug. If I do, then I doubt this is a non-English system problem. The first assertion I got is from GetWinProfile. And what happen is the JavaScript wrapper try to pass two argument to the nsInstall::GetWinProfile. The first is a folder and the second is a string. The first folder should be the "C:\TEMP" however, the JavaScript wrapper code failed to convert the folder value (b0) to a string so the string is "" instead. And that cause the assertion in nsString since we try to access Last() which is CharAt(Length()-1) while Length() == 0.
the thread safe assertion after is from nsInstallInfo::~nsInstallInfo(). I got a lot of them. ssu- are you sure you cannot reproduce this on English system ?
The meaning of Error -229 is defined as below xpinstall/src/nsInstall.h SCRIPT_ERROR = -229 I set a break point at xpinstall/src/nsSoftwareUpdateRun.cpp#420 after call JS_EvaluateScript(cx,glob,scriptBuffer,scriptLength,nsnull,0,&rval); the return value ok is false when the scriptBuffer is the content of psm.jst IS there a way that we can validate psm.jst is a valid JavaScript ?
The thread-safety assertions in the destructor are a known problem but basically harmless. They are not related to this problem in any way except for making debugging extremely annoying and cumbersome. The getFolder("Temporary") results you saw are worrying, but probably not the cause of this problem either because Sean also reproduced it with the spelling checker install which is a much simpler install than psm.
Yes, the script is valid javascript -- it works just fine on an English version of windows. The -229 script error might mean the Javascript compiler couldn't parse the file correctly but that's unlikely since the JS engine shouldn't be sensitive to the OS language. More likely it is a runtime error, basically one of the functions in xpinstall/src/nsJS* files returning JS_FALSE.
I talk to ssu and he show me how to reprouce THIS bug in my system. I try the spellchecker.xpi now since it is simpler. Here is what I got, I set break point at InstallAddDirectory,nsInstall::AddDirectory,InstallSetPackageFolder and nsInstall::SetPackageFolder,InstallFinializeInstall, nsInstall::FinalizeInstall but I hit none of them when the problem occur, this mean the problem is BEFORE them, so, I should check the function verifyDiskSpace.
Strange, the first function in verifyDiskSpace is fileGetDiskSpaceAvailable, I set a break point at nsInstall::FileOpFileGetDiskSpaceAvailable and InstallFileOpFileGetDiskSpaceAvailable. Neither got called when I reproduce the problem. The problem happen even eariler.
I set break point at InstallStartInstall and nsInstall::StartInstall. It got hit and finish ok.
I put break point in InstallLogComment, it got hit once with "startInstall: 0", it then hit the InstallGetFolder and it seems get the correct path of bin directory in the nsILocalFile, but it didn't hit the IntallLogComment for the following line logComment("communicatorFolder: " + communicatorFolder); My theory is the "communicatorFolder: " + communicatorFolder cause some problem.
I think I am right the + cause the problem. I stop at InstallGetFolder and then I set a break point at http://lxr.mozilla.org/seamonkey/source/js/src/jsinterp.c#1992 1992 case JSOP_ADD: 1993 rval = rtmp = POP(); 1994 lval = ltmp = POP(); 1995 VALUE_TO_PRIMITIVE(cx, lval, JSTYPE_VOID, &lval); 1996 if ((cond = JSVAL_IS_STRING(lval)) != 0) { 1997 /* 1998 * Keep lval on the stack so it isn't GC'd during either the 1999 * next VALUE_TO_PRIMITIVE or the js_ValueToString(cx, rval). 2000 */ 2001 sp[0] = lval; 2002 } 2003 VALUE_TO_PRIMITIVE(cx, rval, JSTYPE_VOID, &rval); 2004 if (cond || JSVAL_IS_STRING(rval)) { 2005 if (cond) { and then continue, it stop at the case JSOP_ADD: If I step through, 2003 VALUE_TO_PRIMITIVE(cx, rval, JSTYPE_VOID, &rval); cause the code to get throw to 3434 #if JS_HAS_EXCEPTIONS 3435 /* 3436 * Has an exception been raised? 3437 */ 3438 if (!ok && cx->throwing) {
the value of ok is 0 (FALSE) when this happen. rval = 0x37795c0 and lval=0x3779594 there fore lval is a JSString (the lower three bits is 4 and rval is object since the lower three bits is 0.
The myth got solved. The bug is a combination of 1. the Unicode To ShiftJIS converter return a sucess code (not NS_OK but success) while it should return NS_OK, and 2. the following code compare a nsresult with NS_OK instead of using NS_SUCCEEDED() macro xpinstall/src/nsJSFileSpecObj.cpp 54 PR_STATIC_CALLBACK(JSBool) 55 fso_ToString(JSContext *cx, JSObject *obj, uintN argc, jsval *argv, jsval *rval) .... 69 if(NS_OK != nativeThis->ToString(&stringReturned)) 70 return JS_FALSE; Change the line 69 to 69 if(NS_SUCCEEDED(nativeThis->ToString(&stringReturned))) should make it work (need test) Also, we should fix the nsUnicodeToShiftJIS converter. But either of them should solve this problem.
Whiteboard: [dogfood+][nsbeta2+] → [dogfood+][nsbeta2+]ETA 7/13
I think it is too risky to fix the nsJapaneseToUnicode.cpp now. The safest fix for nsbeta2 is http://warp/u/ftang/fix43272.txt This is very low risk. ssu- please code review and give me an ok. Index: src/nsJSFileSpecObj.cpp =================================================================== RCS file: /m/pub/mozilla/xpinstall/src/nsJSFileSpecObj.cpp,v retrieving revision 1.1 diff -u -r1.1 nsJSFileSpecObj.cpp --- nsJSFileSpecObj.cpp 1999/11/21 01:24:17 1.1 +++ nsJSFileSpecObj.cpp 2000/07/13 06:26:56 @@ -66,7 +66,7 @@ return JS_TRUE; } - if(NS_OK != nativeThis->ToString(&stringReturned)) + if(NS_FAILED( nativeThis->ToString(&stringReturned))) return JS_FALSE; nsJSUtils::nsConvertStringToJSVal(stringReturned, cx, rval); After apply the fix, I succsfully install spellcheck.xpi and psm.xpi. This seems also fix the null string problem I mention eariler.
Whiteboard: [dogfood+][nsbeta2+]ETA 7/13 → [dogfood+][nsbeta2+]fix in hand, need code review
The converter problem filed in 45359. We should take this safe fix for nsbeta2 and fix 45359 after nsbeta2 (unless there are other issue related to it.)
Though the change looks okay, I am not as familiar the this part of the code as Dan is. I would recommend having him give you his blessing.
fix check in. Mark it fix
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
On-line installation of PSM was successful by mozilla nightly 2000071320/Win32(ZIP) on Win95-J.
Verified in 7-13-20 Win32 build.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.