Closed Bug 889937 Opened 7 years ago Closed 7 years ago
Crash while reading a Na
N-Float32/64 from a Data View
Please provide a testcase as an attachment and a crash ID from the about:crashes page.
The div#out should be filled with "NaN", but the browser crashs while loading the file.
Here are some crash IDs from the about:crashes page: bp-df28ab19-9cc3-4e14-8200-b06892130703 bp-6789474a-29db-47f3-90b5-dbfa22130703 bp-49468c32-8ca7-4397-84b5-1efed2130703 bp-c7e5f31c-3e2a-4f20-b966-89f932130703 bp-ef03ee6a-964c-4da5-8b4e-539992130703 bp-8454b825-003c-473c-8604-64bfe2130703 (all related to this bug)
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>) ]
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.)
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.
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. :-)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 859892
You need to log in before you can comment on or make changes to this bug.