Closed Bug 889937 Opened 7 years ago Closed 7 years ago

Crash while reading a NaN-Float32/64 from a DataView

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 859892

People

(Reporter: j.duttke, Unassigned)

References

()

Details

(5 keywords, Whiteboard: maybe PGO related?)

Crash Data

Attachments

(1 file)

340 bytes, text/plain
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

Running the following JavaScript code:
var ab = new ArrayBuffer(4),
    dv = new DataView(ab);

dv.setUint32(0, 0xfffffff6);
console.log(dv.getFloat32(0));


Actual results:

The Browser crashs


Expected results:

The browser should return NaN.
In Firefox 21 this worked without problems.
Please provide a testcase as an attachment and a crash ID from the about:crashes page.
Severity: normal → critical
Flags: needinfo?(j.duttke)
Hardware: x86_64 → x86
Attached file Test case
The div#out should be filled with "NaN", but the browser crashs while loading the file.
Flags: needinfo?(j.duttke)
I don't know if this information helps, but:
The problem also occurs while reading Float64 values, but does not occur while reading integer values from a DataView.
In Nightly: bp-3430ccec-05bf-4119-b086-33fb42130703
In Beta: bp-0e6ec28e-a726-4f6a-ba9a-3ea992130703
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&) ] [@ JSObject::defaultValue(JSContext*, JS::Handle<JSObject*>, JSType, JS::MutableHandle<JS::Value>) ]
Component: Untriaged → JavaScript Engine
Ever confirmed: true
Product: Firefox → Core
Version: 22 Branch → Trunk
getFloat32 clearly has a JS_CANONICALIZE_NAN on trunk, and I would assume on branches, so I dunno what's up here.  But this sort of thing smells of canonicalization failure, so marking s-s for now til someone can really investigate.  (I tried reproducing with a Linux64 shell and don't get any errors, so I don't know what's up here just yet.)
Group: core-security
I can't reproduce either with a 64-bit browser build or a 32-bit browser build on Mac (both the Firefox 22 release build)...
Note that it has bug 799198's signature which is marked as related to PGO.
Today I tried it at work on 3 64bit-Windows 7 systems, and all of them crash.
In Firefox 22 on MacOS X everything works correct.
(In reply to Scoobidiver from comment #8)
> Note that it has bug 799198's signature

You must mean some other bug?
(In reply to Daniel Veditz [:dveditz] from comment #10)
> (In reply to Scoobidiver from comment #8)
> > Note that it has bug 799198's signature
> You must mean some other bug?
Yes. Bug 799118.
These crashes look relatively benign.
Group: core-security
Depends on: 799118
Whiteboard: maybe PGO related?
The problem still occurs in Firefox 23 (Windows)
I'm pretty sure this is a dup of bug 859892, which was just fixed on trunk.  I'm going to optimistically mark it as such (and re-mark as a security bug :-\ ).  But confirmation would still be good.

Jens, could you confirm that this problem no longer reproduces in a current nightly build?  Download it from http://nightly.mozilla.org/ and have it add a desktop shortcut, then add the command line arguments -no-remote --ProfileManager to the shortcut, then run that -- it won't touch your regular Firefox install if you do it that way.  :-)
Group: core-security
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 859892
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.