977403 - Assertion failure: ToInteger(t) == t, at e:\dev\mozilla\central\js\src\jsdate.cpp:278

Status: NEW

(Core :: JavaScript: Standard Library, defect, P5)

Description

[Kelsey Gilbert [:jgilbert]]

I get this sporatically while I'm debugging other things. This fatal assert is really annoying, given its intermittency.

Comment 1

[Kelsey Gilbert [:jgilbert]]

Looks like :waldo's fault:
https://hg.mozilla.org/mozilla-central/annotate/bb9edb4d5144/js/src/jsdate.cpp#l278

Comment 2

[Jeff Walden [:Waldo]]

Kyle's mentioned seeing this too.  It would be extremely helpful in these cases to know where the bad |t| came from.  In his case it came from a Date object with a weird value in one of the reserved slots, but he couldn't backtrack it in a debugger to determine that exact value.  Knowing that value would probably make it trivially easy to create a testcase, and from there a fix.

Comment 3

[Kelsey Gilbert [:jgilbert]]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #2)
> Kyle's mentioned seeing this too.  It would be extremely helpful in these
> cases to know where the bad |t| came from.  In his case it came from a Date
> object with a weird value in one of the reserved slots, but he couldn't
> backtrack it in a debugger to determine that exact value.  Knowing that
> value would probably make it trivially easy to create a testcase, and from
> there a fix.

Alright. I get this fairly often when letting the webgl conformance suite chug away on its own. I'll try to dig into it next time I see this. (And remove the patch I keep that comments this out :P)

Comment 4

[Kelsey Gilbert [:jgilbert]]

Attachment: stacktrace

Comment 5

[Kelsey Gilbert [:jgilbert]]

`t` shows up as: 1.#QNAN00000000000

This value comes from js::DateObject::fillLocalTimeSlots():
  double localTime = LocalTime(utcTime, dtInfo);

`utcTime` looks valid:
  utcTime	1393548142294.0000	double

`dtInfo`:
		localTZA_	-28800000.000000000	double
		offsetMilliseconds	0	__int64
		rangeStartSeconds	1391047070	__int64
		rangeEndSeconds	1393886007	__int64
		oldOffsetMilliseconds	0	__int64
		oldRangeStartSeconds	1391047070	__int64
		oldRangeEndSeconds	1393647160	__int64
		utcToLocalStandardOffsetSeconds	-28800	int


Tracing this back, the result of `AdjustTime(utcTime, dtInfo)` appears to be returning NaN.
`DaylightSavingTA` explicitly returns NaN if `!Finite(t)`, but we already check that earlier in fillLocalTimeSLots(). 

I'll also note that this code seems to be full of double->int conversions, which is happily converting well-behaved NaNs to garbage ints.

Comment 6

[Kelsey Gilbert [:jgilbert]]

I duplicated `utcTime` and `dtInfo` and called LocalTime(), but it gave a normal result. The only thing I can think of would be a race condition with something in `dtInfo`, since LocalTime() is otherwise a pure function.

Comment 7

[Kelsey Gilbert [:jgilbert]]

Actually, getDSTOffsetMilliseconds() does a bunch of non-const modifications. Lemme try to use its data to unwind things.

Comment 8

[Kelsey Gilbert [:jgilbert]]

Yeah, that doesn't matter, since we we already inside either 'window'. I'm out of ideas here. Someone who knows this better should have a look.

Comment 10

[Mayank Bansal]

Kelsey, can you still repro?