Closed Bug 121115 Opened 23 years ago Closed 23 years ago

cannot login to Yahoo! mail when JavaScript enabled

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
DEC
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: dmobrien_2001, Assigned: khanson)

References

(
URL
)

Details

(Keywords: 64bit)

Attachments

(6 files)

testcase
18.99 KB, text/html
Details
new testcase
19.77 KB, text/html
Details
minimal testcase
178 bytes, text/html
Details
test maximum int
624 bytes, text/html
Details
assembly via gdb
4.43 KB, text/plain
Details
reduced testcase
573 bytes, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.7) Gecko/20011226 BuildID: 2001122617 Cannot complete login to Yahoo! mail when JavaScript enabled. What happens is Yahoo! reports invalid password even though correct password is entered. If JavaScript is disabled, then login proceeds correctly. Inspecting the source of the web page reveals complex algorithm to "hash" the user entered password using some kind of MD5 algorithm. My guess is that this is to not send the password as plaintext across the wire. When JavaScript is disabled, then this action is bypassed. PSM is installed and no proxy is involved. Netscape 4.77 works fine on this platform. Same problem exists for groups.yahoo.com and my.yahoo.com. Invalid password with JavaScript enabled. Reproducible: Always Steps to Reproduce: 1.Use DEC Alpha RedHat Linux 7.2 2.browse to http://mail.yahoo.com/ 3.login to Yahoo! Mail Actual Results: Invalid Password Expected Results: Login to Yahoo! Mail
Dan, please stop submitting your bug reports with the severity set to "blocker". This bug does not "block development and/or testing work" in any way. If uncertain, just leave the severity setting at "normal".
Severity: blocker → normal
Can you get a newer build off ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/Red_Hat_7x_RPMS/ ? 0.9.7 is known to have form submission issues
I'm running RH Linux for Dec Alpha. The RPMs on the nightly site appear to all be for i386: mozilla-2002012014_trunk-0_rh7.i386.rpm mozilla-2002012014_trunk-0_rh7.src.rpm mozilla-chat-2002012014_trunk-0_rh7.i386.rpm mozilla-devel-2002012014_trunk-0_rh7.i386.rpm mozilla-dom-inspector-2002012014_trunk-0_rh7.i386.rpm mozilla-js-debugger-2002012014_trunk-0_rh7.i386.rpm mozilla-mail-2002012014_trunk-0_rh7.i386.rpm mozilla-psm-2002012014_trunk-0_rh7.i386.rpm I wonder if this is a 64bit problem in the Script engine since Yahoo! Login page "encrypts" the user password in JavaScript, if enabled.
adding a couple of other DEC linux users in case they can help.
Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.7) Gecko/20011226 worksforme. both "standard" and "secure" work ok.
have you tried Mozilla from a non-Alpha machine? since it doesn't happen to me, perhaps it is specific to your password. perhaps if you change your password it would work. Or have someone else try to log in to Yahoo on your machine.
yes, it works for me on intel. my office mate tried mail.yahoo.com with my alpha build and it failed for him also. when he turned *OFF* javascript, it worked for him.
Are there messages in the JavaScript Console when the login fails? (Tasks|Tools|JavaScript Console)
none are reported. only yahoo returns an invalid password page.
Attached file testcase —
this is a hacked version of the Yahoo login. After you enter your username/password, and hit "Sign In", the resulting URL with hashed info is put into the textbox below the "Sign In" button. If you try this test from multiple computers, it should give you the same hashed URL. The "real" login page Yahoo serves up has random stuff, so the "real" hashed URL should be different every time.
note: see bug 93776 for password issues with Yahoo.
bug 93776 is related to (Yahoo and other sites' use of) the password manager
Attached file new testcase —
This testcase will spew debugging info to the bottom of the HTML page. Works in NS4 and Moz.
Here are the results of the test page: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=71487 NS 4.77 x=1668183396,8416865,0,0,0,0,0,0,0,0,0,0,0,0,48,0 i=0, a=-1820862732 i=0, b=490943820 i=0, c=-1592473376 i=0, d=1016711613 hash2=f4d677934c35431de0c814a1bdc9993c529Fbl.VlegGQJ8sU9FrqxK1P2Z0 MZ x=-479300252,8416865,0,0,0,0,0,0,0,0,0,0,0,0,48,0 i=0, a=-623839284 i=0, b=245358394 i=0, c=462151367 i=0, d=655713835 hash2=ccf7d0da3adf9f0ec7de8b1b2b661527529Fbl.VlegGQJ8sU9FrqxK1P2Z0
For this testcase, you can add: write2div("variable="+variable); in places to see where Mozilla-alpha diverges from other browsers/platforms. I actually get different results between Mozilla-alpha and others (NS4-alpha and Moz-i686). But I am still able to log in to Yahoo, so I'm really quite confused!
Attached file minimal testcase —
output on Moz-alpha: > 1677721600 =? -469762048 output on Moz-i386 and NS4-alpha: > 1677721600 =? 1677721600 Please send this to someone in Javascript.
Attached file test maximum int —
Moz-alpha output: max uint = 1073741824 max uint+1=-1073741823 max int = 1073741824 max int+1=-1073741823 NS4-alpha and Moz-i386 output: max uint = 18014398509481984 max uint+1=18014398509481984 max int = 9007199254740992 max int+1=9007199254740992 Moz-alpha always uses a signed 31-bit integer?!?!?!?!? Overflow is not caught. NS4-alpha and Moz-i386 use a signed 64-bit integer, and where possible, an unsigned 64-bit integer. Overflow is caught in both cases.
.
Assignee: asa → rogerl
Severity: normal → major
Component: Browser-General → JavaScript Engine
Keywords: 64bit
QA Contact: doronr → pschwartau
Reassigning to Kenton; note Comment #14 and what follows, esp. Comment #18
Assignee: rogerl → khanson
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment #18 shows that expression evaluation on the Moz-alpha machine is being done 32 bit signed integer arithmetic. While, NS4-alpha and Moz-i386 expression evaluation is being performed in double precision arithmetic (53 bits of precision). The ECMA standard requires double precision expression evaluation. This probably explains why the Yahoo javascript routines (cited above) do not work on Moz-alpha.
This needs to be fixed for 1.0. khanson, comment #18 actually shows wrapping around a signed *31* bit int, not a signed 32 bit int. That suggests that on Alpha, jsapi.h's INT_FITS_IN_JSVAL is evaluating to true on 0x40000000 (the alleged max uint value reported by the test, but actually one greater than the upper bound of the int-fits-in-jsval domain) for some reason. INT_FITS_IN_JSVAL tests whether ((jsuint)((i)+JSVAL_INT_MAX) <= 2*JSVAL_INT_MAX) for a jsint i. JSVAL_INT_MAX is 0x3fffffff, so the test is asking whether ((jsuint)((0x40000000)+0x3fffffff) <= 0x7ffffffe. Since 0x7fffffff > 0x7ffffffe, I'm not sure what the trouble is. I hope it's not a compiler bug. We need some help diagnosing this. Can anyone with an Alpha system build the js shell (js/src/Makefile.ref) and reduce the testcase? Then I can help debug, if there's a working gdb. /be
Keywords: mozilla1.0+
% make -f Makefile.ref config.mk:137: config/Linux_All.mk: No such file or directory cat: ../../dist/Linux_All_DBG.OBJ/nspr/Version: No such file or directory make: *** No rule to make target `config/Linux_All.mk'. Stop. I seem to be missing a step... there is no Linux_All.mk anywhere in my source tree. gdb ready and waiting.
js/src/config isn't part of the default pull (and yet Makefile.ref -- we move in mysterious ways, it seems). "cvs update -d config" from the js/src directory should do the deed. Sorry about that.
almost there: -------------------------------- % make -f Makefile.ref ... ld -shared -o Linux_All_DBG.OBJ/libjs.o ... \ -Leditline/Linux_All_DBG.OBJ -ledit /usr/bin/ld: cannot find -ledit ... % ls -d editline ls: editline: No such file or directory % cvs update -d editline cvs server: Updating editline % ls -R editline CVS editline/CVS: Entries Repository Root Tag % make -f Makefile.ref cd editline; make -f Makefile.ref all make[1]: Entering directory `/usr/src/mozilla/js/src/editline' make[1]: Makefile.ref: No such file or directory
You'll need to cvs update -d config editline if you are building in a js/src that was pulled as part of SeaMonkeyAll (er, by client.mk). /be
yes, but the editline I pulled from CVS is empty (except for "CVS")
The trunk editline is fine -- are you stuck to the 0.9.9 branch by any chance? I'm sure js/src/editline was not branched, so that could explain it. /be
yup. worked much better with the latest nightly: js> print (1073741824); 1073741824 js> print (1073741824+1); -1073741823
Ok, if you can gdb well, list jsinterp.c:2208 and you should see a line d += d2; Breakpoint there and run, feeding the shell 'i = 1073741824; print (i+1);'. You should hit the breakpoint. Step over it, verify that d is now 1073741825. Now for the tricky bit. The next two lines look like this: sp--; STORE_NUMBER(cx, -1, d); Step over the sp--; and then type display/i $pc to gdb. Then stepi until you are past the STORE_NUMBER(cx, -1, d); line. Then careful copy and paste all the disassembly showing the instructions that were executed into this bug. Finally, p/x sp[-1] before continuing and paste gdb's output here, too. Then continue and verify that the bug bit. /be
Attached file assembly via gdb —
Here ya go.
this bug does not occur using Compaq's cc compiler on Alpha-OSF4. 64-bit integers are used properly.
Actually, I was hoping for the display/i $cp; stepi; stepi;... output, but I may have time to figure out the gcc bug (that's what this is, right?) soon. Or not. Can we open a gcc bug with cygnus and close this report? /be
The attachment is the "display/i $cp; stepi; stepi;..." output. I just removed the "(gdb) stepi" and the "2200 STORE_NUMBER(cx, -1, d)" lines as they were all identical.
Oh, thanks! I should have watched addresses jump at branches. But please confirm that this is a gcc bug (and file one with gcc folks, for bonus points). /be
On further investigation of what "/i" and "$pc" I think I've figured out what you were wanting. "/i" is redundant in that case, and it confused gdb. I'll attach what you really wanted shortly.
Nope. guess it was ok. display $pc just gives the address as an integer...
in the STORE_NUM macro, cc/OSF does: v_ = INT_TO_JSVAL(i_); and gcc/Linux does: ok = js_NewDoubleValue(cx, d, &v_); if (!ok) goto out; I will do some more debugging to figure out why, but that might be enough of a hint for you to figure out what's going on.
nope. me="crack smoker" BTW: js seg faults if I recompile without clobbering...
me!="crack smoker" with gcc/Linux, INT_FITS_IN_JSVAL(i_) returns true, while it does not on OSF. i_=(hex)40000001 from JSDOUBLE_IS_INT(d, i_) on both compilers. INT_FITS_IN_JSVAL(i_) returns true on gcc/Linux, but not cc/OSF
Ajschult, right -- that's what I was on about in comment #22. Can you isolate the gcc-generated instruction sequence for just INT_FITS_IN_JSVAL(i_)? /be
my line 2238 is sandwiched between sp-- and STORE_NUM. ----------------------------------------------------------- (gdb) p /x testi_ $2 = 0x40000001 (gdb) display /i $pc 1: x/i $pc 0x12005bcf0 <js_Interpret+34960>: ldq t0,144(fp) (gdb) stepi 2238 if ((jsuint)((testi_)+JSVAL_INT_MAX) <= 2*JSVAL_INT_MAX) 1: x/i $pc 0x12005bcfc <js_Interpret+34972>: ldl t1,456(fp) 1: x/i $pc 0x12005bd00 <js_Interpret+34976>: ldah t0,16384(zero) 1: x/i $pc 0x12005bd04 <js_Interpret+34980>: subl t0,0x1,t0 1: x/i $pc 0x12005bd08 <js_Interpret+34984>: addl t1,t0,t0 1: x/i $pc 0x12005bd0c <js_Interpret+34988>: addl t0,zero,t1 1: x/i $pc 0x12005bd10 <js_Interpret+34992>: ldah t0,16384(zero) 1: x/i $pc 0x12005bd14 <js_Interpret+34996>: ldah t0,16384(t0) 1: x/i $pc 0x12005bd18 <js_Interpret+35000>: lda t0,-2(t0) 1: x/i $pc 0x12005bd1c <js_Interpret+35004>: cmple t1,t0,t0 1: x/i $pc 0x12005bd20 <js_Interpret+35008>: beq t0,0x12005bd3c <js_Interpret+35036> -------------------------------------------------------------------------- the LHS evaluates to (hex)8000000 and the RHS evaluates to 7ffffffe on OSF and Linux.
>the LHS evaluates to (hex)8000000 and the RHS evaluates to 7ffffffe on OSF and >Linux. Do you mean 8000000 or 80000000? I hope the latter! /be
Can you show the code that Compaq's cc produces on Alpha-OSF64 for the same testi inline-expansion of INT_FITS_IN_JSVAL? Thanks, /be
ya, 8000000 I'll serve up the OSF shortly. I wrote a test c program with "unsigned int" in place of "uint32" and "int" in place of "int32" and it also took the bait. ------------------------------------------------------------ #define JSVAL_INT_POW2(n) ((long)1 << (n)) #define JSVAL_INT_MAX (JSVAL_INT_POW2(30) - 1) int main() { int i; long j; i=1073741825; printf ("%x %x\n", i, j); printf ("%x %x\n", (unsigned int)((i)+JSVAL_INT_MAX), 2*JSVAL_INT_MAX); if ((unsigned int)((i)+JSVAL_INT_MAX) <= 2*JSVAL_INT_MAX) {printf ("doh\n");} return 0; } ---------------------------------------------------------------- output: got it
output="doh". used to be "got it" but that made the line too long...
[JSBool js_Interpret(JSContext*, jsval*):2239 0x120066724] ldah r0, 16384(r31) [JSBool js_Interpret(JSContext*, jsval*):2239 0x120066728] lda r0, -1(r0) [JSBool js_Interpret(JSContext*, jsval*):2239 0x12006672c] addl r12, r0, r0 [JSBool js_Interpret(JSContext*, jsval*):2239 0x120066730] zapnot r0, 0xf, r0 [JSBool js_Interpret(JSContext*, jsval*):2239 0x120066734] ldah r1, 16384(r31) [JSBool js_Interpret(JSContext*, jsval*):2239 0x120066738] lda r1, -1(r1) [JSBool js_Interpret(JSContext*, jsval*):2239 0x12006673c] sll r1, 0x1, r1 [JSBool js_Interpret(JSContext*, jsval*):2239 0x120066740] cmple r0, r1, r0 [JSBool js_Interpret(JSContext*, jsval*):2239 0x120066744] beq r0, 0x120066764
Attached file reduced testcase —
looks like a compiler bug. cc on OSF does not bit the bug.
filed a bug with RedHat with an even simpler testcase. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=61154
Thanks for all the hard work in tracking this down! Since it turned out to be a compiler bug, I will now resolve this report, as suggested in Comment #33. I don't see a satisfactory keyword for this type of situation; since it's not a bug in JS Engine, the closest one seems to be "INVALID".
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Marking Verified -
Status: RESOLVED → VERIFIED
*** Bug 119952 has been marked as a duplicate of this bug. ***
*** Bug 181873 has been marked as a duplicate of this bug. ***
FYI: this bug has been fixed in gcc CVS and Compaq/HP has released an updated gcc package with the fix. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9164 http://alpha.crl.dec.com/bugzilla/show_bug.cgi?id=32
*** Bug 220732 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: