Stop caching jsdIValues, it doesn't seem to be worth the lookup cost. This has the side effect of plugging the leak, as described in the bug.
also...
* Convert a few raw pointers to nsCOMPtrs
* Fix a bug where removing the last filter did not null out the list head,
causing a crash the next time filters were used.
* Track live jsdStackFrames, so we can invalidate them all when execution
continues. Without this, only the top frame is properly invalidated, and any
other frame accessed after a continue will do Bad Things.
* Add some debugging prints to GetInitAtService, which seems to be failing at
random times.
git-svn-id: svn://10.0.0.236/trunk@123613 18797224-902f-48f8-a5cc-f745e15eee43
I keep getting syntax errors with no line numbers as well.
That happens when I use Context.compileReader(..) to compile the script. The
DefaultErrorReporter will throw an exception with only the message and not the
line it happened on.
It is of course easy to workaround using your own error reporter, but I've
attached a patch to add on the line and source name so the DefaultErrorReporter
gives the similar output as EcmaError if that is wanted.
git-svn-id: svn://10.0.0.236/trunk@123421 18797224-902f-48f8-a5cc-f745e15eee43
> Norris Boyd wrote:
>
> Igor Bukaniv wrote:
> >
> > I am curios, why there is a need to have a special JSObject support in Rhino? Was it used for anything? The implementation in the ICEbrowser does not use it as in rare cases where conversion from JSObject to/from JS type may be needed (like calling JSObject.getWindow from a script), it seems that WrapHandler (or similar modifications to pre Rhino 1.5R2 sources) and Wrapper are enough to cover all the cases.
> Yes, we should probably just remove the JSObject code. We added it early on when Rhino was first written and we thought we might need JSObject compatibility with the JS + Java implementation in Navigator 4.x. That's not important now, so we should just remove this code (which likely doesn't work at this point anyway).
git-svn-id: svn://10.0.0.236/trunk@123139 18797224-902f-48f8-a5cc-f745e15eee43
the code should not call setWrapFactory with null argument, but use new WrapFactory to restore default behaviour
git-svn-id: svn://10.0.0.236/trunk@122959 18797224-902f-48f8-a5cc-f745e15eee43
given the following object :
----------------------------------------------
function SomeObject() {}
SomeObject.prototype.exec = function() {
var local = this.someField;
}
----------------------------------------------
i create an 'instance', set a field and call the exec method :
----------------------------------------------
var someField = "global field value";
var anInstance = new SomeObject();
anInstance.someField = "instance field value";
anInstance.exec();
----------------------------------------------
then the local variable 'local' in the exec() method is assigned the value
of the global 'someField' variable instead of the instance field value.
the problem seems to be in the ScriptRuntime.callOrNewSpecial() method,
which is called, because the parser treats the name 'exec' specially. in
this method the exec() method gets called with
return call(cx, fun, thisArg, args, scope);
where the 'thisArg' parameter really is the global this value instead of
the dynamic this value, which is in the jsThis variable and which would be
the one needed...
is it legitimate to replace the above call in callOrNewSpecial() with the
following line :
return call(cx, fun, jsThis, args, scope);
this seems to only happen for methods named 'exec', which are identified as
special in the NodeTransformer.isSpecialCallName() method.
any help is appreciated. thank you very much for your time.
kind regards,
felix
git-svn-id: svn://10.0.0.236/trunk@122320 18797224-902f-48f8-a5cc-f745e15eee43
