305838 - calDateTime.nativeTime = Number.NaN causes crash

Status: RESOLVED DUPLICATE of bug 324293

(Calendar :: Internal Components, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050824 Mozilla Sunbird/0.2+

Setting 
  calDateTime.nativeTime = Number.NaN 
or 
  calDateTime.nativeTime = undefined
causes immediate crash.

Reproducible: Always

Steps to Reproduce:
    var testDate = (Components
                    .classes["@mozilla.org/calendar/datetime;1"]
                    .createInstance(Components.interfaces.calIDateTime));
    testDate.nativeTime = Number.NaN; // or undefined

Actual Results:  
Crash with message
  The instruction at "0x00823ff3" referenced memory at "0x00000000".
  The memory could not be "read".

(Crash is immediate:  items written to js console just before this do not appear.)

Expected Results:  
Should not crash.

Option A:  throw an exception.

Option B:  put calDateTime into an "undefined date" state (like new
Date(undefined) in javascript).

Option C:  don't change the date.  

During development, (A) is easiest to debug if an error occurs, but when
deployed may cause users problems (because exception is not caught and thus
aborts a whole chain of methods).

(B) is harder to debug, but is more graceful degradation during deployment that (A).

(C) is hardest to debug, and gives user no clue that anything is wrong.

So (B) seems like best approach for XUL/JavaScript.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

A) is the proper solution.  If your code is assigning NaN into .nativeTime, your
code has a bug that needs to be fixed.

Comment 2

[gekacheka]

Upon reconsideration, it looks like it has to be (A) because the interface is
defined in terms of ints, and there is no NaN for ints.

(An invalid javascript date returns NaN from its methods.)

(I was wishing that a more graceful degradation such as (B) was possible because
a small bug rendered sunbird unusable, and this kind of fragility could also
occur in xul applications/forms that use calDateTime.  JavaScript code is not
typechecked, and forms are often not well covered by tests, so unexpected
exceptions are more likely to occur and break applications/forms.  That's good
reason for Javascript Date to behave as it does.)

Comment 3

[Mike Shaver (:shaver emeritus)]

Unfortunately, I do not have cycles to work on Calendar stuff these days (just as it's getting to the good part!), so I am a bad owner for these bugs.  To delete the tragically-large chunk of bugspam, search for gregorianabdication.

Comment 4

[Stefan Sitter [:ssitter]]

Extract of callstack when following the steps above:

00 sunbird!icaltime_from_timet_with_zone(long tm = -2077252342, int is_date = 0, struct _icaltimezone * zone = 0x013cb410)+0x3b 
   [d:/dev/mozilla/calendar/libical/src/libical/icaltime.c @ 192]

01 sunbird!calDateTime::SetTimeInTimezone(int64 aTime = -9223372036854775808, class nsACString_internal * aTimezone = 0x0012a594)+0xb6 
   [d:/dev/mozilla/calendar/base/src/calDateTime.cpp @ 332]

02 sunbird!calDateTime::SetNativeTime(int64 aNativeTime = -9223372036854775808)+0x2a 
   [d:/dev/mozilla/calendar/base/src/calDateTime.cpp @ 233]

03 xpcom_core!XPTC_InvokeByIndex(class nsISupports * that = 0x02c5b0f0, unsigned int methodIndex = 8, unsigned int paramCount = 1, struct nsXPTCVariant * params = 0x0012a728)+0x27 
   [d:/dev/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp @ 102]

04 sunbird!XPCWrappedNative::CallMethod(class XPCCallContext * ccx = 0x0012a8b4, XPCWrappedNative::CallMode mode = CALL_SETTER (2))+0xf37 
   [d:/dev/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp @ 2152]

05 sunbird!XPCWrappedNative::SetAttribute(class XPCCallContext * ccx = 0x0012a8b4)+0xe 
   [d:/dev/mozilla/js/src/xpconnect/src/xpcprivate.h @ 1983]

Same crash location as in Bug 324293 Comment #3.

Comment 5

[Joey Minta]

(In reply to comment #4)
> Same crash location as in Bug 324293 Comment #3.
> 
Yeah, marking as a dupe, since that bug has the right dependency tree.


*** This bug has been marked as a duplicate of 324293 ***