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)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
firefox41 --- affected
firefox42 --- fixed

People

(Reporter: decoder, Assigned: anba)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(1 file, 1 obsolete file)

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()>
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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.
(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]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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.
Attached patch bug1177907-check-exception (obsolete) (deleted) — Splinter Review
Attachment #8627625 - Flags: review?(till)
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+
Attached patch bug1177907-check-exception (deleted) — Splinter Review
Addressed nits and updated patch subject.
Assignee: nobody → andrebargull
Attachment #8627625 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8627643 - Flags: review+
Keywords: checkin-needed
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)
(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)
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*)
Blocks: 1179003
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: