789893 - Crash [@ js::EncapsulatedPtr] with Proxy in Proxy

Status: RESOLVED DUPLICATE of bug 793160

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 9677eb19a6a5 (run with -m -n -a):


p = Proxy.create({})
new Proxy(p,Proxy);

Comment 1

[Christian Holler (:decoder)]

Likely a harmless crash:

==2043== Invalid read of size 8
==2043==    at 0x4154CC: js::EncapsulatedPtr<js::Shape, unsigned long>::operator js::Shape*() const (Barrier.h:172)
==2043==    by 0x406B53: js::ObjectImpl::lastProperty() const (ObjectImpl.h:1125)
==2043==    by 0x408353: JSObject::getParent() const (jsobjinlines.h:244)
==2043==    by 0x5CF7BC: proxy(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3120)
==2043==    by 0x533419: js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:372)
==2043==    by 0x53355D: js::CallJSNativeConstructor(JSContext*, int (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:407)
==2043==    by 0x53C485: js::InvokeConstructorKernel(JSContext*, JS::CallArgs) (jsinterp.cpp:430)
==2043==    by 0x54A3A4: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:2402)
==2043==    by 0x7A4F4D: js::mjit::EnterMethodJIT(JSContext*, js::StackFrame*, void*, JS::Value*, bool) (MethodJIT.cpp:1043)
==2043==    by 0x7A5153: CheckStackAndEnterMethodJIT(JSContext*, js::StackFrame*, void*, bool) (MethodJIT.cpp:1074)
==2043==    by 0x7A5252: js::mjit::JaegerShot(JSContext*, bool) (MethodJIT.cpp:1086)
==2043==    by 0x53B9FF: js::RunScript(JSContext*, JSScript*, js::StackFrame*) (jsinterp.cpp:298)
==2043==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   103906:05adc6145143
user:        Eddy Bruel
date:        Thu Aug 30 17:17:29 2012 +0100
summary:     Bug 703537 - Implement Harmony Direct Proxies; r=jorendorff

Comment 3

[Eddy Bruel [:ejpbruel]]

Proxy.create is the constructor for the old proxies. There is some code sharing between those and the new *direct* proxies, but I doubt its related to this crash.

Comment 4

[Scoobidiver (away)]

Regression and Trunk don't tell you which versions are affected.

Comment 5

[Christian Holler (:decoder)]

(In reply to Scoobidiver from comment #4)
> Regression and Trunk don't tell you which versions are affected.

You can use the status flags to indicate what version is affected or not. Please do not change the version field from Trunk to anything else if it's a JS bug that has been reported on trunk. JSBugMon does not understand any versions other than "Trunk" and will ignore the bug then (which will cause the bug to be excluded from automated tracking and bisection).

Also if trunk moves to 19 now and the bug has not been fixed yet until that, the version field will indicate something wrong.

Comment 6

[Scoobidiver (away)]

(In reply to Christian Holler (:decoder) from comment #5)
> Please do not change the version field from Trunk to anything else if it's a
> JS bug that has been reported on trunk. JSBugMon does not understand any
> versions other than "Trunk" and will ignore the bug then (which will cause
> the bug to be excluded from automated tracking and bisection).
There is a bunch of JS bugs that follow the standard rules (Version field for the version it first appeared): https://bugzilla.mozilla.org/buglist.cgi?keywords=crash%2C%20regression%2C%20;keywords_type=allwords;list_id=4548662;field0-0-0=version;resolution=---;query_format=advanced;type0-0-0=notequals;value0-0-0=Trunk;component=JavaScript%20Engine;product=Core

> Also if trunk moves to 19 now and the bug has not been fixed yet until that,
> the version field will indicate something wrong.
It depends on the meaning you give to the Version field when regression is a keyword. In the JS way, the tracking flag needs to be updated every six weeks, e.g. status-firefox19 in a few days.

Comment 7

[Christian Holler (:decoder)]

(In reply to Scoobidiver from comment #6)

> It depends on the meaning you give to the Version field when regression is a
> keyword. In the JS way, the tracking flag needs to be updated every six
> weeks, e.g. status-firefox19 in a few days.

Our understanding of the Version field is unrelated to any keywords. If the version field is != Trunk, then it means that *only* this branch specified is affected. There is no other field that allows specifying what branch this is on, and there is more than just mozilla-central. That's also why we use "Other branch" for non-mc bugs. And we've been filing thousands of bugs this way and I don't know about any standard rules about that field.

If you use the version field for the first version it appeared in, then I think the status- flags for older versions are pointless and also it's impossible for automation to know if it should be able to reproduce the bug on the most recent version. This is important though for automated tracking of JS bugs that can be reproduced fully automatically (which is what bugmon does).

Comment 8

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision b2bdbfe06b10).

Comment 9

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   112693:5a98250eb00c
user:        Eddy Bruel
date:        Thu Nov 08 16:51:11 2012 +0100
summary:     Bug 793160 - Add NULL check for proto; r=ejpbruel

This iteration took 115.827 seconds to run.

Comment 11

[Christian Holler (:decoder)]

A testcase for this bug was already added in the original bug (bug 793160).