Closed Bug 852099 Opened 11 years ago Closed 3 years ago

Crash [@ PropertyAccess<(PropertyAccessKind)0>] or Crash [@ js::EncapsulatedPtr]

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
critical

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;
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]
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]
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.
Crash Signature: [@ PropertyAccess<(PropertyAccessKind)0>] [@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->] → [@ PropertyAccess<(PropertyAccessKind)0>] [@ js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->()]
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:]
JSBugMon: Cannot process bug: Unknown exception (check manually)
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]
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]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 00b264c7cced).
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]
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]
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.
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->()]
The isTypedArray() call on the stack now is gone, at least.
Flags: needinfo?(bhackett1024)
Assignee: general → nobody
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-
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 → ---

Closing this one with Works for me since there havent been any crashes for the past 6 months.

Status: REOPENED → RESOLVED
Closed: 6 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.