Closed Bug 43272 Opened 24 years ago Closed 24 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: 24 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: 24 years ago → 24 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.