1343608 - Assertion failure: YearFromTime(t) == year, at js/src/jsdate.cpp:191

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 1bc2ad020aee (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu, run with --fuzzing-safe min.js):

var juneDate = new Date(2000, 5, 20, 1e21, 0, 0, 0);


Backtrace:

 received signal SIGSEGV, Segmentation fault.
0x08540718 in DayWithinYear (t=3.6000000000000009e+27, year=1.1407945862452315e+17) at js/src/jsdate.cpp:191
#0  0x08540718 in DayWithinYear (t=3.6000000000000009e+27, year=1.1407945862452315e+17) at js/src/jsdate.cpp:191
#1  0x08540a18 in DateFromTime (t=3.6000000000000009e+27) at js/src/jsdate.cpp:238
#2  0x08540db5 in DaylightSavingTA (t=3.6000000000000009e+27) at js/src/jsdate.cpp:446
#3  0x08540f08 in AdjustTime (date=3.6000000000000009e+27) at js/src/jsdate.cpp:459
#4  0x08540fd9 in UTC (t=3.6000000000000009e+27) at js/src/jsdate.cpp:474
#5  0x08576a3d in DateMultipleArguments (args=..., cx=0xf793a800) at js/src/jsdate.cpp:3216
#6  js::DateConstructor (cx=0xf793a800, argc=7, vp=0xf5250060) at js/src/jsdate.cpp:3233
#7  0x08174dd7 in js::CallJSNative (cx=0xf793a800, native=0x8576600 <js::DateConstructor(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:282
[....]
#20 main (argc=3, argv=0xffffd8e4, envp=0xffffd8f4) at js/src/shell/js.cpp:8369
eax	0x0	0
ebx	0x8cf9ff4	147824628
ecx	0xf7da4864	-136689564
edx	0x0	0
esi	0x7c4	1988
edi	0xffffcdac	-12884
ebp	0xffffcc08	4294953992
esp	0xffffcbd0	4294953936
eip	0x8540718 <DayWithinYear(double, double)+200>
=> 0x8540718 <DayWithinYear(double, double)+200>:	movl   $0x0,0x0
   0x8540722 <DayWithinYear(double, double)+210>:	ud2    


This issue seems to be 32-bit only.

Comment 1

[André Bargull [:anba]]

This issue could be compiler specific. I was able to reproduce it with GCC 5.4.0 (Ubuntu x64 16.04), but not with Clang 3.8.0.

Comment 2

[Jeff Walden [:Waldo]]

In a recent clang-tip build with -fsanitize=undefined as a compiler option:

[jwalden@find-waldo-now src]$ dbg/js/src/js -e 'var juneDate = new Date(2000, 5, 20, 1e21, 0, 0, 0);'
/home/jwalden/moz/slots/intl/icu/source/common/ucmndata.c:239:56: runtime error: index 93 out of bounds for type 'UDataOffsetTOCEntry const[2]'
/home/jwalden/moz/slots/js/src/dbg/dist/include/mozilla/FloatingPoint.h:348:39: runtime error: value 9.0072e+15 is outside the range of representable values of type 'int'
/home/jwalden/moz/slots/js/src/jit/x86-shared/Assembler-x86-shared.h:3628:9: runtime error: load of misaligned address 0x0b1630fe1756 for type 'uintptr_t' (aka 'unsigned long'), which requires 8 byte alignment
0x0b1630fe1756: note: pointer points here
 00 00 49 bb ff ff  ff ff ff ff ff ff 41 53  6a 00 85 c0 0f 84 3f 00  00 00 83 f8 01 0f 84 20  01 00
             ^ 
/home/jwalden/moz/slots/js/src/jit/x86-shared/Assembler-x86-shared.h:3629:9: runtime error: store to misaligned address 0x0b1630fe1756 for type 'uintptr_t' (aka 'unsigned long'), which requires 8 byte alignment
0x0b1630fe1756: note: pointer points here
 00 00 49 bb ff ff  ff ff ff ff ff ff 41 53  6a 00 85 c0 0f 84 3f 00  00 00 83 f8 01 0f 84 20  01 00
             ^ 
/home/jwalden/moz/slots/js/src/jsdate.cpp:445:45: runtime error: value 1.14079e+17 is outside the range of representable values of type 'int'
/home/jwalden/moz/slots/js/src/jsdate.cpp:426:19: runtime error: value -7.84353e+11 is outside the range of representable values of type 'int'
/home/jwalden/moz/slots/js/src/dbg/dist/include/js/SweepingAPI.h:55:20: runtime error: call to function (unknown) through pointer to incorrect function type 'void (*)(void **)'
(/home/jwalden/moz/slots/js/src/dbg/js/src/shell/js+0x3950e50): note: (unknown) defined here
/home/jwalden/moz/slots/js/src/dbg/dist/include/js/Class.h:881:5: runtime error: call to function (unknown) through pointer to incorrect function type 'void (*)(js::FreeOp *, JSObject *)'
(/home/jwalden/moz/slots/js/src/dbg/js/src/shell/js+0x3006d80): note: (unknown) defined here

Dollars to donuts, one of those FloatingPoint.h or jsdate.cpp problems is implicated by this, and we're misusing C++ somewhere.

Comment 3

[Nathan Froyd [:froydnj]]

Waldo, are you able to look into this any further?

Comment 4

[Jeff Walden [:Waldo]]

Not any time in the next four months.  :-(  Wanted to get to this, but I've run out of time at this point, so making that non-action status clear here if someone else wants to take.  I still this is almost certainly a matter of running comment 2 to ground.

Comment 5

[Nathan Froyd [:froydnj]]

Marking wontfix for 54, then.

Comment 6

[Jan de Mooij [:jandem]]

NI Waldo since this is probably in date and/or MFBT code.

Comment 7

[André Bargull [:anba]]

Hmm, maybe it's just a GCC cross-compilation issue for floating point operations. 

Derived from https://searchfox.org/mozilla-central/source/js/src/tests/non262/Date/timeclip.js
---
#include <iostream>
#include <iomanip>
#include <limits>
#include <string>

int main() {
    using namespace std;

    // Avoid compile-time evaluation of the addition.
    string s("8.64e15 0.5000000000000001");
    string::size_type end;
    double v = stod(s, &end);
    double w = stod(s.substr(end));
    double r = v + w;
    cout << setprecision(std::numeric_limits<double>::digits10 + 1) << r << endl;

    return 0;
}
---

`g++ -m32 -o a.out -std=c++11 a.cpp && ./a.out` prints "8640000000000000", whereas `g++ -o a.out -std=c++11 a.cpp && ./a.out` prints "8640000000000001". 

Tested with various optimizations levels and gcc-4.9, gcc-5.4 (both VirtualBox, Ubuntu 16.04), gcc-7.2 (VirtualBox, Ubuntu 17.10), and gcc-7.2 (native, Ubuntu 17.10). When the floating precision level is set to 64-bit, we get the expected result: `g++ -m32 -o a.out -std=c++11 -mpc64 a.cpp && ./a.out` prints "8640000000000001".

Recompiling SpiderMonkey with "-mpc64" avoids the assertion error for the test case in comment #0 (configure options: `CC="/usr/bin/gcc -m32 -mpc64" CXX="/usr/bin/g++ -m32 -mpc64" ../configure --enable-debug --enable-optimize --disable-tests --target=i686-pc-linux`).

Comment 8

[Fuzzing Team]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Not sure who to ping here. Should we resolve this, ever since we've moved (I think) entirely to clang on most/all platforms that we care about?

Comment 10

[Jan de Mooij [:jandem]]

Comment 2 from Waldo suggests it might be undefined behavior on our side. In that case we should probably keep it open anyway.

Comment 11

[André Bargull [:anba]]

Instead of using -mpc64 it also seems possible to use -mfpmath=sse -msse -msse2 and by that ensure GCC always emits SSE instructions even when compiling for x86-32. (The internet says that GCC defaults to x87-fpu instructions for x86-32 and sse-fpu instructions for x86-64.)

Using the test case from comment #7:

/tmp$ g++-9 -m32 -o a.out -std=c++11 b.cpp && ./a.out                                       
8640000000000000
/tmp$ g++-9 -mfpmath=sse -msse -msse2 -m32 -o a.out -std=c++11 b.cpp && ./a.out
8640000000000001

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:sdetar, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 13

[Nicolas B. Pierron [:nbp]]

Nicolas, can you check if this issue still exist on x86.