If I cause an error-exception to be thrown (via a strict warning and JSOPTION_WERROR, in this case), and I haven't initialized the standard classes, lazily or otherwise, we crash in js_ConstructObject: #0 0x08092d36 in js_ConstructObject (cx=0x80d8a28, clasp=0x80d36e0, proto=0x0, parent=0x0, argc=3, argv=0x80e0000) at jsobj.c:1745 1745 parent = OBJ_GET_PARENT(cx, ctor); (gdb) list 1743 ctor = JSVAL_TO_OBJECT(cval); 1744 if (!parent) 1745 parent = OBJ_GET_PARENT(cx, ctor); (gdb) bt #0 0x08092d36 in js_ConstructObject (cx=0x80d8a28, clasp=0x80d36e0, proto=0x0, parent=0x0, argc=3, argv=0x80e0000) at jsobj.c:1745 #1 0x08071aa3 in js_ErrorToException (cx=0x80d8a28, message=0x80de050 "assignment to undeclared variable i", reportp=0xbffff1e0) at jsexn.c:846 #2 0x08056e94 in ReportError (cx=0x80d8a28, message=0x80de050 "assignment to undeclared variable i", reportp=0xbffff1e0) at jscntxt.c:308 ... What should we do here? I'm not sure, at this hour of the morning, but I wanted to get it on file before I slept.
Created attachment 71851 [details] [diff] [review] a JSVAL_VOID constructor is just like not finding it I thought about having js_ConstructObject return an unconstructed object if we couldn't find the constructor, but then I realized how dumb that was. This just treats the can't-find-ctor case like the error-looking-for-ctor case, and they really are pretty much equivalent as far as js_ConstructObject is concerned. I get error reports via the ErrorReporter, because of the fallback logic in ReportError, and all seems well. The only possible problem, I guess, is that we don't throw an exception, but I don't think we want to hand-construct the error object. Do we?
Created attachment 71963 [details] [diff] [review] revised proposed fix shaver and I chatted on IRC and I pointed out that we need to report an error if js_ConstructObject is to return null for successful call to FindConstructor that returned JSVAL_VOID (or any primitive value). I'm rolling this patch up in the larger patch in bug 127136. /be
Attachment #71851 - Attachment is obsolete: true
Created attachment 71965 [details] [diff] [review] whoops, too fast on the draw -- real proposed fix We don't need the static helper ReportIsNotFunction here, we haven't pushed any frame for the constructor yet. See the commment in ReportIsNotFunction further down in jsobj.c. /be
Attachment #71963 - Attachment is obsolete: true
Comment on attachment 71965 [details] [diff] [review] whoops, too fast on the draw -- real proposed fix sr=shaver. Want the bug?
Attachment #71965 - Flags: superreview+
This went in already, as part of the patch for bug 127136. /be
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Mike, did this fix the crash? If so, could you verify this one for me? Thanks -
Yep, all better.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.