cannot login to Yahoo! mail when JavaScript enabled




JavaScript Engine
16 years ago
14 years ago


(Reporter: Dan O'Brien, Assigned: Kenton Hanson (gone))




Firefox Tracking Flags

(Not tracked)




(6 attachments)



16 years ago
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 and
Invalid password with JavaScript enabled.

Reproducible: Always
Steps to Reproduce:
1.Use DEC Alpha RedHat Linux 7.2
2.browse to
3.login to Yahoo! Mail

Actual Results:  Invalid Password

Expected Results:  Login to Yahoo! Mail

Comment 1

16 years ago
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

Comment 2

16 years ago
Can you get a newer build off ? 0.9.7 is
known to have form submission issues

Comment 3

16 years ago
I'm running RH Linux for Dec Alpha.   The RPMs on the nightly site appear to all
be for i386:

I wonder if this is a 64bit problem in the Script engine since Yahoo! Login page
"encrypts" the user password in JavaScript, if enabled.

Comment 4

16 years ago
adding a couple of other DEC linux users in case  they can help.

Comment 5

16 years ago
Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.7) Gecko/20011226
worksforme.  both "standard" and "secure" work ok.

Comment 6

16 years ago
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.

Comment 7

16 years ago
yes, it works for me on intel.

my office mate tried with my alpha build and it failed for him
also.  when he turned *OFF* javascript, it worked for him.

Comment 8

16 years ago
Are there messages in the JavaScript Console when the login fails?
(Tasks|Tools|JavaScript Console)


Comment 9

16 years ago
none are reported.  only yahoo returns an invalid password page.

Comment 10

16 years ago
Created attachment 69380 [details]

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.

Comment 12

16 years ago
bug 93776 is related to (Yahoo and other sites' use of) the password manager

Comment 14

16 years ago
Created attachment 71487 [details]
new testcase

This testcase will spew debugging info to the bottom of the HTML page.	Works
in NS4 and Moz.

Comment 15

16 years ago
Here are the results of the test page:

NS 4.77


i=0, a=-1820862732

i=0, b=490943820

i=0, c=-1592473376

i=0, d=1016711613




i=0, a=-623839284

i=0, b=245358394

i=0, c=462151367

i=0, d=655713835


Comment 16

16 years ago
For this testcase, you can add:


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!

Comment 17

16 years ago
Created attachment 71496 [details]
minimal testcase

output on Moz-alpha:
> 1677721600 =? -469762048

output on Moz-i386 and NS4-alpha:
> 1677721600 =? 1677721600

Please send this to someone in Javascript.

Comment 18

16 years ago
Created attachment 71504 [details]
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.

Comment 19

16 years ago
Assignee: asa → rogerl
Severity: normal → major
Component: Browser-General → JavaScript Engine
Keywords: 64bit
QA Contact: doronr → pschwartau

Comment 20

16 years ago
Reassigning to Kenton; note Comment #14 and what follows, esp. Comment #18
Assignee: rogerl → khanson


16 years ago
Ever confirmed: true

Comment 21

16 years ago
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
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.

Keywords: mozilla1.0+

Comment 23

16 years ago
% make -f Makefile.ref config/ 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/'.  Stop.

I seem to be missing a step...  there is no 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.

Comment 25

16 years ago
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

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


Comment 27

16 years ago
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.


Comment 29

16 years ago
yup.  worked much better with the latest nightly:

js> print (1073741824);   
js> print (1073741824+1);
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:

                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.


Comment 31

16 years ago
Created attachment 73826 [details]
assembly via gdb

Here ya go.

Comment 32

16 years ago
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?


Comment 34

16 years ago
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).


Comment 36

16 years ago
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.

Comment 37

16 years ago
Nope.  guess it was ok.  display $pc just gives the address as an integer...

Comment 38

16 years ago
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.

Comment 39

16 years ago
nope.  me="crack smoker"

BTW: js seg faults if I recompile without clobbering...  

Comment 40

16 years ago
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_)?


Comment 42

16 years ago
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   
the LHS evaluates to (hex)8000000 and the RHS evaluates to 7ffffffe on OSF and
>the LHS evaluates to (hex)8000000 and the RHS evaluates to 7ffffffe on OSF and

Do you mean 8000000 or 80000000?  I hope the latter!

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,


Comment 45

16 years ago
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;
   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;
got it

Comment 46

16 years ago
output="doh".  used to be "got it" but that made the line too long...

Comment 47

16 years ago
[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

Comment 48

16 years ago
Created attachment 74022 [details]
reduced testcase

looks like a compiler bug.  cc on OSF does not bit the bug.

Comment 49

16 years ago
filed a bug with RedHat with an even simpler testcase.

Comment 50

16 years ago
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".
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 51

16 years ago
Marking Verified -

Comment 52

16 years ago
*** Bug 119952 has been marked as a duplicate of this bug. ***

Comment 53

16 years ago
*** Bug 181873 has been marked as a duplicate of this bug. ***

Comment 54

15 years ago
FYI: this bug has been fixed in gcc CVS and Compaq/HP has released an updated
gcc package with the fix.

Comment 55

14 years ago
*** 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.