Closed Bug 305838 Opened 19 years ago Closed 18 years ago

calDateTime.nativeTime = Number.NaN causes crash

Categories

(Calendar :: Internal Components, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 324293

People

(Reporter: gekacheka, Unassigned)

Details

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.
A) is the proper solution.  If your code is assigning NaN into .nativeTime, your
code has a bug that needs to be fixed.
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.)
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.
Assignee: shaver → nobody
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.
(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 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.