Closed Bug 121115 Opened 23 years ago Closed 22 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: 22 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: