Closed
Bug 852099
Opened 11 years ago
Closed 3 years ago
Crash [@ PropertyAccess<(PropertyAccessKind)0>] or Crash [@ js::EncapsulatedPtr]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: decoder, Unassigned)
Details
(Keywords: crash, testcase, Whiteboard: [jsbugmon:update,ignore])
Crash Data
The following testcase crashes on mozilla-central revision b03bb3ce8cee (run with --ion-eager): gczeal(4); gcparam("maxBytes", gcparam("gcBytes") + 4*1024); var scratchZ = {}; scratchZ.r = scratchZ.i = 0;
Reporter | ||
Comment 1•11 years ago
|
||
It looks like a null-deref due to OOM: Program received signal SIGSEGV, Segmentation fault. 0x08063972 in js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator-> (this=0x5) at ../../gc/Barrier.h:169 169 T *operator->() const { return value; } (gdb) bt #0 0x08063972 in js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator-> (this=0x5) at ../../gc/Barrier.h:169 #1 0x0804e142 in js::ObjectImpl::getClass (this=0x1) at ../../vm/ObjectImpl.h:1108 #2 0x080511d9 in JSObject::isTypedArray (this=(const JSObject * const) 0x1 Cannot access memory at address 0x1) at ../../jsobjinlines.h:898 #3 0x081d8a11 in PropertyAccess<(PropertyAccessKind)0> (cx=0x8cafaa0, script=0xf7425098, pc=0x8d1b6fa "6", object=0xf741e1c0, target=0x8d1c448, idArg=$jsid("r")) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:1127 #4 0x081ecd19 in TypeConstraintProp<(PropertyAccessKind)0>::newType (this=0x8d1c490, cx=0x8cafaa0, source=0x8d1c3f8, type=...) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:1250 #5 0x080d3499 in js::types::TypeCompartment::resolvePending (this=0x8cd25b8, cx=0x8cafaa0) at ../jsinferinlines.h:1147 #6 0x080d3c3a in js::types::TypeSet::addType (this=0x8d10e58, cx=0x8cafaa0, type=...) at ../jsinferinlines.h:1466 #7 0x081d26f0 in js::types::TypeMonitorResult (cx=0x8cafaa0, script=0xf7425098, pc=0x8d1b6ea "\232", rval=...) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:5767 #8 0x081f338b in js::types::TypeScript::Monitor (cx=0x8cafaa0, script=0xf7425098, pc=0x8d1b6ea "\232", rval=...) at /srv/repos/mozilla-central/js/src/jsinferinlines.h:929 #9 0x0820e9d1 in js::Interpret (cx=0x8cafaa0, entryFrame=0xf7698028, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:2521 #10 0x081f93bb in js::RunScript (cx=0x8cafaa0, fp=0xf7698028) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:323 #11 0x081fb6f6 in js::ExecuteKernel (cx=0x8cafaa0, script=0xf7425098, scopeChainArg=(JSObject &) @0xf7421040 [object global] delegate, thisv=..., type=js::EXECUTE_GLOBAL, evalInFrame=..., result=0x0) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:531 #12 0x081fb9a2 in js::Execute (cx=0x8cafaa0, script=0xf7425098, scopeChainArg=(JSObject &) @0xf7421040 [object global] delegate, rval=0x0) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:571 #13 0x080b9bfe in JS_ExecuteScript (cx=0x8cafaa0, objArg=(JSObject *) 0xf7421040 [object global] delegate, scriptArg=0xf7425098, rval=0x0) at /srv/repos/mozilla-central/js/src/jsapi.cpp:5535 #14 0x08052f25 in Process (cx=0x8cafaa0, obj_=(JSObject *) 0xf7421040 [object global] delegate, filename=0xffffd199 "min.js", forceTTY=false) at /srv/repos/mozilla-central/js/src/shell/js.cpp:468 #15 0x08062974 in ProcessArgs (cx=0x8cafaa0, obj_=(JSObject *) 0xf7421040 [object global] delegate, op=0xffffcea4) at /srv/repos/mozilla-central/js/src/shell/js.cpp:5030 #16 0x08062b59 in Shell (cx=0x8cafaa0, op=0xffffcea4, envp=0xffffcff4) at /srv/repos/mozilla-central/js/src/shell/js.cpp:5067 #17 0x080636ea in main (argc=3, argv=0xffffcfe4, envp=0xffffcff4) at /srv/repos/mozilla-central/js/src/shell/js.cpp:5291 (gdb) f 3 #3 0x081d8a11 in PropertyAccess<(PropertyAccessKind)0> (cx=0x8cafaa0, script=0xf7425098, pc=0x8d1b6fa "6", object=0xf741e1c0, target=0x8d1c448, idArg=$jsid("r")) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:1127 1127 if (object->singleton && object->singleton->isTypedArray() && JSID_IS_VOID(id)) { (gdb) p object $1 = (js::types::TypeObject *) 0xf741e1c0 (gdb) p object->singleton $2 = (JSObject *) 0x1 Cannot access memory at address 0x1 It would be very nice to fix this, as I suspect it's causing a few OOM crash signatures. Brian, you are probably most familar with this code I assume?
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->]
Flags: needinfo?(bhackett1024)
Summary: Crash [@ PropertyAccess<(PropertyAccessKind)0>] → Crash [@ PropertyAccess<(PropertyAccessKind)0>] or Crash [@ js::EncapsulatedPtr]
Whiteboard: [jsbugmon:update,bisect]
Reporter | ||
Updated•11 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Reporter | ||
Comment 2•11 years ago
|
||
JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 119272:7b531a62b114 user: Brian Hackett date: Fri Jan 18 09:23:28 2013 -0700 summary: Bug 772820 - Disallow GCs during script analysis or compilation, r=billm. This iteration took 13.670 seconds to run.
Updated•11 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
Reporter | ||
Updated•11 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
Whiteboard: [jsbugmon:update] → [jsbugmon:]
Reporter | ||
Comment 3•11 years ago
|
||
JSBugMon: Cannot process bug: Unknown exception (check manually)
Reporter | ||
Updated•11 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
Whiteboard: [jsbugmon:] → [jsbugmon:update]
Reporter | ||
Updated•11 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
Reporter | ||
Comment 4•11 years ago
|
||
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 00b264c7cced).
Updated•11 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:update,bisectfix]
Reporter | ||
Updated•11 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
Whiteboard: [jsbugmon:update,bisectfix] → [jsbugmon:update,ignore]
Reporter | ||
Comment 5•11 years ago
|
||
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 00b264c7cced). JSBugMon: Fix Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: 127424:ae738d911ded parent: 127423:3d370087403a parent: 125135:b2636816c7fd user: Jan de Mooij date: Mon Mar 18 16:53:57 2013 +0100 summary: Merge from mozilla-central. This iteration took 1.519 seconds to run. Oops! We didn't test rev 3d370087403a, a parent of the blamed revision! Let's do that now. We did not test rev 3d370087403a because it is not a descendant of either b03bb3ce8cee or 00b264c7cced. Rev 3d370087403a: Found cached shell... Testing... [Uninteresting] It didn't crash. (0.956 seconds) good (not interesting) As expected, the parent's label is the opposite of the blamed rev's label. Bisect lied to us! Parent rev 3d370087403a was also good! Oops! We didn't test rev b2636816c7fd, a parent of the blamed revision! Let's do that now. Rev b2636816c7fd: Updating... Compiling... Testing... Exit status: CRASHED signal 11 (SIGSEGV) (0.057 seconds) bad (interesting) As expected, the parent's label is the opposite of the blamed rev's label. Bisect blamed the merge because our initial range did not include one of the parents. The common ancestor of 3d370087403a and b2636816c7fd is 3df2b971c106. Rev 3df2b971c106: Found cached shell... Testing... Exit status: CRASHED signal 11 (SIGSEGV) (0.236 seconds) bad (interesting) Consider re-running autoBisect with -s 3df2b971c106 -e ae738d911ded in a configuration where earliestWorking is before the common ancestor.
Comment 6•11 years ago
|
||
autoBisect tripped over, here. Likely an inaccurate fix window, so let's probably just land the testcase.
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
Comment 7•11 years ago
|
||
The isTypedArray() call on the stack now is gone, at least.
Flags: needinfo?(bhackett1024)
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•9 years ago
|
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()] → [@ PropertyAccess<(PropertyAccessKind)0>]
[@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
[@ PropertyAccess<T>]
[@ js::EncapsulatedPtr<T>::operator-
Comment 8•6 years ago
|
||
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Reopening because crash bugs **with testcases** should not be resolved **as WONTFIX** based on queries of crash-stats. Other resolutions may be appropriate for other reasons. (Crash signatures are not the same as bug identity; they're merely a search aid to find and group similar crashes. The bug may still be present, but the signature may have changed slightly, or the bug may even still be present with the same signature but there are simply no recent reports of crashes in that function.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 10•3 years ago
|
||
Closing this one with Works for me since there havent been any crashes for the past 6 months.
Status: REOPENED → RESOLVED
Closed: 6 years ago → 3 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•