Closed
Bug 1177907
Opened 9 years ago
Closed 9 years ago
Assertion failure: !cx->isExceptionPending(), at js/src/jscntxtinlines.h:238 with evalcx
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla42
People
(Reporter: decoder, Assigned: anba)
References
Details
(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
anba
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision 0b2f5e8b7be5 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe):
b = {};
b.__proto__ = evalcx(("new Date('1/1/1999 13:30 PM')"));
function g() {
g(b.toString())
}
g();
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000698a33 in js::CallJSNative (cx=0x7ffff691b4e0, native=0xb10440 <date_toString(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:238
#0 0x0000000000698a33 in js::CallJSNative (cx=0x7ffff691b4e0, native=0xb10440 <date_toString(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:238
#1 0x0000000000687f42 in js::Invoke (cx=cx@entry=0x7ffff691b4e0, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:709
#2 0x0000000000689cc9 in js::Invoke (cx=cx@entry=0x7ffff691b4e0, thisv=..., fval=..., argc=<optimized out>, argv=0x7fffffdff598, rval=...) at js/src/vm/Interpreter.cpp:766
#3 0x0000000000b93a54 in js::DirectProxyHandler::call (this=this@entry=0x1a54b00 <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0x7ffff691b4e0, proxy=..., proxy@entry=..., args=...) at js/src/proxy/DirectProxyHandler.cpp:77
#4 0x0000000000b9a63b in js::CrossCompartmentWrapper::call (this=0x1a54b00 <js::CrossCompartmentWrapper::singleton>, cx=0x7ffff691b4e0, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:289
#5 0x0000000000ba6c72 in js::Proxy::call (cx=cx@entry=0x7ffff691b4e0, proxy=proxy@entry=..., args=...) at js/src/proxy/Proxy.cpp:391
#6 0x0000000000ba6d2e in js::proxy_Call (cx=0x7ffff691b4e0, argc=<optimized out>, vp=<optimized out>) at js/src/proxy/Proxy.cpp:697
#7 0x00000000006988d2 in js::CallJSNative (cx=0x7ffff691b4e0, native=0xba6c90 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
#8 0x000000000068822d in js::Invoke (cx=cx@entry=0x7ffff691b4e0, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:697
#9 0x0000000000689cc9 in js::Invoke (cx=cx@entry=0x7ffff691b4e0, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x7fffffdff728, rval=..., rval@entry=...) at js/src/vm/Interpreter.cpp:766
#10 0x0000000000a2ade9 in js::jit::InvokeFunction (cx=0x7ffff691b4e0, obj=..., constructing=<optimized out>, argc=0, argv=0x7fffffdff720, rval=...) at js/src/jit/VMFunctions.cpp:75
#11 0x00007ffff7fed81f in ?? ()
#12 0x0000000000000000 in ?? ()
rax 0x0 0
rbx 0x7ffff691b4e0 140737330132192
rcx 0x7ffff6ca588d 140737333844109
rdx 0x0 0
rsi 0x7ffff6f7a9d0 140737336814032
rdi 0x7ffff6f791c0 140737336807872
rbp 0x7fffffdfe100 140737486250240
rsp 0x7fffffdfe0b0 140737486250160
r8 0x7ffff7fcc780 140737353926528
r9 0x6372732f736a2f6c 7165916604736876396
r10 0x7fffffdfde70 140737486249584
r11 0x7ffff6c27ee0 140737333329632
r12 0x7fffffdfe9e8 140737486252520
r13 0x0 0
r14 0x7fffffdfe0c0 140737486250176
r15 0xb10440 11600960
rip 0x698a33 <js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)+643>
=> 0x698a33 <js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)+643>: movl $0xee,0x0
0x698a3e <js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)+654>: callq 0x495700 <abort()>
Reporter | ||
Updated•9 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 1•9 years ago
|
||
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/982cf335aaa7
user: Oleg Romashin
date: Mon May 18 18:13:56 2015 -0700
summary: Bug 1165918 - Qt widget port does not compile anymore. r=rojkov
This iteration took 413.399 seconds to run.
Comment 2•9 years ago
|
||
(In reply to Christian Holler (:decoder) from comment #1)
> JSBugMon: Bisection requested, result:
> autoBisect shows this is probably related to the following changeset:
>
> The first bad revision is:
> changeset: https://hg.mozilla.org/mozilla-central/rev/982cf335aaa7
> user: Oleg Romashin
> date: Mon May 18 18:13:56 2015 -0700
> summary: Bug 1165918 - Qt widget port does not compile anymore. r=rojkov
>
> This iteration took 413.399 seconds to run.
Doesn't seem likely.
Whiteboard: [jsbugmon:update] → [jsbugmon:update,bisect]
Reporter | ||
Updated•9 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 3•9 years ago
|
||
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/0f13750b63e7
user: Ehsan Akhgari
date: Wed May 13 18:34:12 2015 -0400
summary: Bug 1164487 - Part 2: Update the interfaces tests; r=baku
This iteration took 352.118 seconds to run.
Assignee | ||
Comment 4•9 years ago
|
||
Attachment #8627625 -
Flags: review?(till)
Comment 5•9 years ago
|
||
Comment on attachment 8627625 [details] [diff] [review]
bug1177907-check-exception
Review of attachment 8627625 [details] [diff] [review]:
-----------------------------------------------------------------
Great, thanks! r=me with the tiny nit addressed and the patch subject changed to something like "Bug 1177907 - Handle ObjectClassIs exception in date_toString. r=till". Patch subjects should describe what the patch does, if at all possible.
::: js/src/jsdate.cpp
@@ +2888,3 @@
> tv = unboxed.toNumber();
> }
> + /* Return if there was an error in ObjectClassIs. */
Nit: //-style comment, please. Also, I'd prefer something like "ObjectClassIs can throw for objects from other compartments": as it is, the comment doesn't really add much in the way of explanation to the code.
Attachment #8627625 -
Flags: review?(till) → review+
Assignee | ||
Comment 6•9 years ago
|
||
Addressed nits and updated patch subject.
Assignee: nobody → andrebargull
Attachment #8627625 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8627643 -
Flags: review+
Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Comment 7•9 years ago
|
||
This will need a try server run to be checked in by sheriffs. Do you have level 1 commit access and can do the try run? If so, a simple one-platform run with just the relevant suites should suffice.
Flags: needinfo?(andrebargull)
Assignee | ||
Comment 8•9 years ago
|
||
(In reply to Till Schneidereit [:till] from comment #7)
> This will need a try server run to be checked in by sheriffs. Do you have
> level 1 commit access and can do the try run? If so, a simple one-platform
> run with just the relevant suites should suffice.
No, I don't have any commit access.
Flags: needinfo?(andrebargull)
Comment 9•9 years ago
|
||
Comment 10•9 years ago
|
||
Keywords: checkin-needed
Comment 11•9 years ago
|
||
I find this super concerning, ObjectClassIs should never throw an exception. If this happens here this is a bug and we should not paper over it. (Or change ObjectClassIs *sigh*)
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox42:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in
before you can comment on or make changes to this bug.
Description
•