There's a new crash in Firefox 3.5.6 with the signature "SetDateToNaN" that hasn't been seen in any of the versions 3.5,3.5.1,3.5.2,3.5.3,3.5.4,3.5.5. So far we've seen 10+ of these crashes in the wild. stack looks like http://crash-stats.mozilla.com/report/index/1206d9bf-9449-45f6-966e-44ed02091217 Frame Module Signature [Expand] Source 0 js3250.dll SetDateToNaN js/src/jsdate.cpp:962 1 NPSWF32.dll NPSWF32.dll@0xa7f47 2 NPSWF32.dll NPSWF32.dll@0xaa929 3 NPSWF32.dll NPSWF32.dll@0xec834 4 NPSWF32.dll NPSWF32.dll@0x13829d 5 nspr4.dll dtoa nsprpub/pr/src/misc/prdtoa.c:2823 6 NPSWF32.dll NPSWF32.dll@0x13882d with jsdate.cpp changing during 3.5.6 development 18fb758d910b 2009-11-10 05:40 +0100 Igor Bukanov - bug 524121 r=brendan a1.9.1.6=dveditz see http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.5.6&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=SetDateToNaN&do_query=1 for more crash info.

Igor, can you see anything of interest in these stacks?

(In reply to comment #1) > Igor, can you see anything of interest in these stacks? No: SetDateToNaN is static in jsdate.cpp yet none of the stacks AFAICS contains any of SetDateToNaN callers from that file. So it is hard to tell what is going there.

Is it possible to search crashes for any function coming from js/src/jsdate.cpp? I want to see if this crash is completely new or there were similar ones in 3.5.5.

Could be some incorrect offset in a corrupt table somewhere, but probably have to look at minidumps to find out. Mmm, minidumps.

re: comment 3 I have a couple of requests in to get that kind of reporting, but right now its a pretty tedious process. https://bugzilla.mozilla.org/show_bug.cgi?id=519703#c4 would help here but we also need to have general purpose search for the top 5 (or N) frames of the stack.

This appears to be a Flash bug based on an examination of a minidump. Here's what the crash is: static void SetDateToNaN(JSContext *cx, JSObject *obj, jsval *vp = NULL) { JS_ASSERT(OBJ_GET_CLASS(cx, obj) == &js_DateClass); jsval nan = DOUBLE_TO_JSVAL(cx->runtime->jsNaN); // *** Crash here, usually with crash addr 0x14. obj->fslots[JSSLOT_LOCAL_TIME] = nan; obj->fslots[JSSLOT_UTC_TIME] = nan; if (vp) *vp = nan; } The caller, which is in NPSWF32.dll, passes 0 for obj, which makes the fslots store crash witha address 0x14, and it's clear this function doesn't want to take a NULL |obj| argument.

cliss, can you help out here? I looked at a handful of reports and they all look like flash 10.0.22.87

dvander and I looked at the disassembly some more. It appears that we are getting here from a call instruction in npswf32.dll that only pushes 2 arguments on the stack. Also, the JS function we are crashing in is a static function, so it should not be possible for Flash to call it directly. So, we think there is some bug in Flash where it is calling to a "random" address that is inside JS. It is possible that the fix to bug 524121 introduced this crash by changing the code that appears at the random address jumped to, but I'm thinking the fix didn't "cause" the problem in terms of actually doing anything bad itself.

With Flash debug symbols, if those crashes still exist, they will be tracked in another bug. I close it as invalid.

Version and milestone values are being reset to defaults as part of product refactoring.