(More work is needed to conform to ECMA ed. 3 by removing Closure objects; also we want more efficient closure calling, soon.)
- Move mislocated call to js_FoldConstants from jsemit.c's js_EmitTree, the TOK_FUNCTION case, back to jsparse.c. This avoids redundant fold-walks over non-top-level functions. Folding should be done at tree-gen time, not at code-gen time.
- Eliminate dead code in if-else and ?: when folding constants.
- Release tempPool arena space before early return on error in js_FoldConstants, just to be nice (all arena space gets released eventually, when the compiler finishes).
Use nsCOMPtr to manage services (thank you dp, thank you).
Only push context on stack when actually executing JS via JSAPI.
Use nsXPIDLCString to simplify memory management (thank you waterson,
thank you).
Use generic module stuff.
r=fur,jband
make all targets "other_window" to reduce number of open windows.
* mklistpage.pl
make all targets "other_window" to reduce number of open windows.
* runtests2.pl
more hacking, still not done.
- jsinterp.c changes:
__- JSOP_CLOSURE comment fixes.
____(NB: ECMA ed 3 seems to require that we abolish the Closure object altogether, replacing it with a new Function object where we used to make a new closure. That says we should use JS_CloneFunctionObject or an internal form (js_).)
__- Use obj rather than the same-valued fp->scopeChain as fourth argument to js_ConstructObject.
__- JSOP_DEFFUN change to auto-clone when running a script in a different scope from the one the compiler used for static function scope linkage.
__- Remove bogus assertion from JSOP_DEFVAR/CONST: case.
- jsparse.c/.h changes:
__- Restored outerFun test to FunctionDef in jsparse.c, so that we make a closure if (outerFun || lambda || !funAtom) -- i.e., if we're compiling
____- A function statement within an active function via eval;
____- We're compiling a function expression statement (not at apparent-to-compiler top-level; part of some kind of compound statement, e.g. if or with);
____- Or the function, even at top statement level and not in another function, has no name.
__- Don't predefine local variables at compile time if they're in with statement
__- Enforce const at compile time for local consts
- Minor jsemit.[ch] cleanup.
- teach loader about unloading and deferring components
- turn off some DEBUG_shaver noise
- better error reporting
- use nsXPIDLCString
- use nsCOMPtr
- add missing cxstack->Pop() in the xpcshell
- Components.results.NS_ERROR_FACTORY_REGISTER_AGAIN (want better text for
error message)
- handle thrown-nsresult correctly where C++ calls JS without an active JS
stack
- remove missing cxstack->Pop() from TestXPC
r=jband,brendan
("[PP]Crash on startup because of Java Plug-in 1.3 for Netscape
Navigator.") Make the code more bulletproof by checking for NULL
arguments to several methods. If JVM isn't running, jEnv arg should
be NULL.
This doesn't entirely fix the problem of a JVM gone awry in all cases;
in the case of this particular bug, the Sun JDK 1.3 Beta HotSpot VM
caused an error, and there's no way for Mozilla code to detect this
failure mode. The fix for that half of the problem is to use the new
JDK 1.3 Early Access VM, which does not exhibit the problem.
to the xpconnect echo interface. This will help fix bug 17736. This includes
using nsITimer which is a pretty messed up xpcom interface w/o a factory.
- Added dump() to xpcshell to make it compatible with browsers debug
output method.
- reformat beard's leak fix to follow 80 column rule.
- Add a missing dont_AddRef to avoid a leak in some debug code.
r=mccabe
object - There's no clear documentation of the result, but the source
code unambiguously calls 'js_obj_toSource', which inserts the extra '()'
under the version1_2 flag, so I believe this is the correct result.
- Fix for bug 13419 - xpconnect calls wrapped JS objects on wrong JSContext.
Added code to use the nsThreadJSContextStack in order to call wrapped
JS object on the JSContext that is current for the running thread.
We've made the rule that xpconnect only supports one JSRuntime. We
partially enforce that here by enforcing that the JSContext on which
we will run code hails from the same JSRuntime as the JSContext on
which the wrapper for the JS code was built.
Because it is perfectly legal for the nsThreadJSContextStack to be empty
if a wrapped JS object is being called from code other than a DOM event,
this system will lazily create a JSContext for the current thread and
maintain it in TLS. This JSContext is used as necessary. If it uses such
a JSContext that was not already on the nsThreadJSContextStack then the
system will temporarily push that JSContext onto the nsThreadJSContextStack
during the course of the function call being performed. This is all managed
my a new auto class: AutoPushCompatibleJSContext. This is used in the two
places where wrapped JS code is called from native code.
[the two places where this system is invoked are currently disabled due to
the fact that the DOM code makes bad assumptions about the JSContext on
which DOM objects can be accessed. We are working to fix that and then this
code will be enabled.]
- Add #ifdef XPC_DETECT_LEADING_UPPERCASE_ACCESS_ERRORS code that will help
users when we do things like fix bug 14460. As soon as we make more of the
idl declarations of methods leadingLowercase then we will have
LeadingUppercase calls from JS breaking at runtime. It is expected that this
will especially be a problem for coders working with the same interfaces
from both C++ and JS (since from C++ an interface has LeadingUpper methods and
the *same* interface seen from JS has leadingLowecase names). This code
(as suggested by shaver) will print out an informative error message when
it detects the misuse. This is currently enabled for DEBUG builds only.
- Copy code from xpcshell to TestXPC to use the JSRuntimeSerivce.
r=norris@netscape.com
- Check to see if a wrapped JS object has a QueryInterface property before
trying to call that method. This is a speed optimization. It also and makes
norris happy because his perrenial breakpoint in jsReportErrorNumber is not
getting hit (even though the old code was safe).
code review and fixes (r=chouck@geocast.com). He needs this cuz he has no
knowledge of exact number of properties before new-style enumerating them.
- Patch up jsdbgapi.c a bit -- it needs to use OBJ_GET_ATTRIBUTES and new APIs
to do a better job describing properties to a debugger.
- Add JSMSG_CANT_DESCRIBE_PROPS for bogus non-native error case in jsdbgapi.c.
- Fix "Inappropriate" => "invalid" in JSMSG_BAD_ARRAY_LENGTH message.
Primarily fixes to properly handle nsIXPCSecurityManager vetos of
xpconnect activities.
- The code was not propagating security manager vetos of native wrapping up
through xpconnect internals. So, xpconnect was erroneously masking the
security exception with its own 'failed to convert param' exception.
This effects the signatures of nsXPCWrappedNative::GetNewOrUsedWrapper
and nsXPCWrappedJSClass::GetNewOrUsedClass.
- This propagation also helps with the problem that sometimes interfaces
are not set as [scriptable] and we did not make that clear as the source
of xpconnect's failure to convert a param in calling a method. Now this
specific class of exceptions is indicated in the JS exception object when
this happens.
- Added an explicit call to js_ForceGC on shutdown of xpcshell to aid in
avoiding 'false positives' in leak detection
- Return JS_FALSE rather than JS_TRUE when an exception is thrown in
xpcjsid to make the jsengine notices the exception.
- Move #includes that others added in xpcmodule.cpp to xpcprivate.h in
order to maintain the include conventions of this module.
- Avoid throwing an exception if it represents a security manager veto
and the security manager set an exception already.
- Replace uses of nsCOMTypeInfo<> added by scc with NS_GET_IID macros.
- Fixed a methodname misspelling because reviewers care about stuff
like that :)
Subject:
Re: another getClassLoader exception
Date:
Mon, 18 Oct 1999 22:01:24 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com (Norris Boyd)
CC:
Howard Lin <howard@softcom.com>
References:
1 , 2
At 05:03 PM 10/18/99 -0700, Norris Boyd wrote:
>Are you still seeing this problem?
Yes. I just did a CVS update to get the latest stuff and we still have
this problem.
I wrote a standalone sample program that duplicates the problem. Run
JSSupport and you should get this exception:
defineClass org.mozilla.javascript.gen.c2
Exception in thread "main" java.lang.NoClassDefFoundError:
org/mozilla/javascript/gen/c1
at java.lang.ClassLoader.resolveClass0(Native Method)
at java.lang.ClassLoader.resolveClass(ClassLoader.java:545)
at
JSSupport$MySecuritySupport$DataClassLoader.loadClass(JSSupport.java:89)
at JSSupport$MySecuritySupport.defineClass(JSSupport.java:47)
at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java,
Compiled Code)
at org.mozilla.javascript.Context.compile(Context.java:1761)
at org.mozilla.javascript.Context.compile(Context.java:1691)
at org.mozilla.javascript.Context.compileReader(Context.java:810)
at org.mozilla.javascript.Context.evaluateReader(Context.java:725)
at org.mozilla.javascript.Context.evaluateString(Context.java:692)
at JSSupport.<init>(JSSupport.java:20)
at JSSupport.main(JSSupport.java:9)
Andrew
>--N
>
>Andrew Wason wrote:
>
> > At 04:54 PM 10/12/99 -0700, Norris Boyd wrote:
> > >I just checked in changes so that the class calling ScriptRuntime (c5
> in your
> > >case) will load the class itself using the normal Java classloading
> mechanism
> > >rather than an explicit call to the class loader. I pushed the bits up
> to the
> > >ftp site, but it takes a bit to propagate.
> >
> > I get this exception now (debugging statements are from my code):
> >
> > SecuritySupport.defineClass org.mozilla.javascript.gen.c5
> > DataClassLoader.loadClass org.mozilla.javascript.gen.c5
> > DataClassLoader.loadClass org.mozilla.javascript.gen.c4
> > using default loader com.softcom.realjava.PluginClassLoader@da9486a0
> > java.lang.NoClassDefFoundError: org/mozilla/javascript/gen/c4
> > at java.lang.ClassLoader.resolveClass0(Native Method)
> > at java.lang.ClassLoader.resolveClass(ClassLoader.java:545)
> > at
> >
> com.softcom.realjava.plugins.RealJavaScript$RealJavaScriptSecuritySupport$Da
> > taClassLoader.loadClass(RealJavaScript.java:410)
> > at
> >
> com.softcom.realjava.plugins.RealJavaScript$RealJavaScriptSecuritySupport.de
> > fineClass(RealJavaScript.java:352)
> > at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java,
> > Compiled Code)
> > at org.mozilla.javascript.Context.compile(Context.java:1761)
> > at org.mozilla.javascript.Context.compile(Context.java:1691)
> > at org.mozilla.javascript.Context.compileReader(Context.java:810)
> >
> > So when c5 is being loaded by my SecuritySupport, it also needs to load c4.
> > I decompiled org.mozilla.javascript.gen.c5 and it's constant pool
> > references CLASS org.mozilla.javascript.gen.c4, so c5 is dependent on c4
> > being loadable. Is the problem that c5 is being loaded before the
> > optimizer has defined c4?
> >
> > I get the above exception for some classes and not others. It seems
> > consistent that I always get it for classes with dependencies on other
> > optimizer classes that haven't been generated yet.
> >
> > Andrew
> >
> > --
> > Andrew Wason
> > SoftCom, Inc.
> > aw@softcom.com
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
JSSupport.java
Name:
JSSupport.java
Type:
Java Source File (text/java)
Encoding:
base64
Implement nsIXPCNativeCallContext to meet user feature
requirements. This allows simpler implementation of reflection of
native classes into JavaScript in cases where they need to
support legacy interfaces that include optional parameters and
method name overloading. This also provides a general mechanism
for native methods to discover if they were called from JS code,
exactly what JS parameters were passed, explicitly return jsvals,
and throw explicit jsvals without interference from xpconnect.
With test cases.
2. Cleaned up ugly JS_GC_Flag typedef name and put XXXbe comment in there for
next time: someone seems to have patched around a deadlock that has since
bit chouck@geocast.com.
3. Fixed gcDisabled by moving it from cx to rt and updating it atomically.
4. Fixed ECMA violation where for (var i, j in o) ... was permitted; only one
variable is allowed.
(Item 4 was a bug on rogerl's list, since closed? r=shaver@mozilla.org.)
- Fixed two similar cases where code was missing one level of
pointer dereference in terminating a copied string. Was trashing
data further up the stack.
- Use 'nsAllocator::Free' in two similar cases where 'delete' was
mistakenly used. Error pointed out by Purify.
- Fixed leaked nsID ptr. bug 16373. This alsothrows a JS
exception when JS callers call createInstance or getService
using an (optional) param that is not an iid. This had been a
'XXX' in the code.
- Moved a release call out of just the error condition block in
setting up a ServiceReleaser. I should have caught this one, but
few of my tests use services :( I have hopes that the whole
ServiceReleaser will become unnecessary as the ServiceManager
system changes and simply calling NS_RELEASE on a service becomes
sufficient.
- Cleaned up an addref/release pair in a setter (need to move to
nsComPtrs!) r=beard
* fixed a typo that caused a warning (nsIsupports)
* fixed values of constants that caused warnings
* use a macro instead of assinging a long long value directly
r=jband
Subject:
another getClassLoader exception
Date:
Tue, 12 Oct 1999 10:39:26 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com (Norris Boyd)
CC:
Howard Lin <howard@softcom.com>
Norris,
It looks like the classes the optimizer generates call
ScriptRuntime.defineFunction which calls getClassLoader. This throws a
SecurityException.
java.security.AccessControlException: access denied
(java.lang.RuntimePermission getClassLoader )
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java
, Compiled Code)
at java.security.AccessController.checkPermission(AccessController.java,
Compiled Code)
at java.lang.SecurityManager.checkPermission(SecurityManager.java, Compiled
Code)
at java.lang.Class.getClassLoader(Class.java, Compiled Code)
at
org.mozilla.javascript.ScriptRuntime.defineFunction(ScriptRuntime.java:2045)
at org.mozilla.javascript.gen.c5.initScript(order.js)
at org.mozilla.javascript.gen.c5.exec(order.js)
at org.mozilla.javascript.Context.evaluateReader(Context.java:728)
[...]
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
Subject:
optimizer SecurityException
Date:
Mon, 11 Oct 1999 17:37:51 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com (Norris Boyd)
CC:
Howard Lin <howard@softcom.com>
We use our own SecuritySupport implementation in Rhino. This is properly
getting called by the optimizer to generate new classes (e.g.
org.mozilla.javascript.gen.c5 etc.)
However, after defining the class, Codegen.compile calls getClassLoader()
on the new class. The default SecurityManager doesn't allow
getClassLoader() to be called and so an exception is thrown:
java.lang.RuntimeException: Malformed optimizer package
java.security.AccessControlException: access denied
(java.lang.RuntimePermission getClassLoader )
at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java:138)
at org.mozilla.javascript.Context.compile(Context.java:1761)
at org.mozilla.javascript.Context.compile(Context.java:1691)
at org.mozilla.javascript.Context.compileReader(Context.java:810)
at org.mozilla.javascript.Context.evaluateReader(Context.java:725)
[...]
This is kind of a pain to duplicate outside of our application, but if you
require a test case I can create one.
Codegen is attempting to call loadClass() after it uses
SecuritySupport.defineClass(). Our SecuritySupport calls loadClass()
internally in its defineClass() implementation. This is what JavaAdapter
expects.
This is from Codegen.compile():
if (securitySupport == null) {
if (Context.isSecurityDomainRequired())
throw new SecurityException("Required " +
"security context missing");
if (classLoader == null)
classLoader = new JavaScriptClassLoader();
clazz = classLoader.defineClass(name, classFile);
} else {
clazz = securitySupport.defineClass(name,
classFile,
securityDom
securityDomain);
}
ClassLoader loader = clazz.getClassLoader();
clazz = loader.loadClass(name);
This is from JavaAdapter.createAdapterClass():
SecuritySupport ss = cx.getSecuritySupport();
if (ss != null) {
Object securityDomain = cx.getSecurityDomainForStackDepth(-1);
return ss.defineClass(adapterName, bytes, securityDomain);
} else {
if (classLoader == null)
classLoader = new MyClassLoader();
classLoader.defineClass(adapterName, bytes);
return classLoader.loadClass(adapterName, true);
}
So JavaAdapter is assuming SecuritySupport.defineClass() will call
ClassLoader.loadClass() on the new class, while Codegen is assuming it
needs to call ClassLoader.loadClass() on the class defined by
SecuritySupport.defineClass().
These should be made consistent, and in both cases it should be assumed
that SecuritySupport will both define and load the class.
Andrew
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
- map xpcshell's 'quit()' to a loop exit rather than calling
'exit(0)' so that the cleanup and leak detection code will still
get called.
- add NS_InitXPCOM and NS_ShutdownXPCOM to xpcshell to run said
cleanup and leak detection code.
- use more NS_IF_* macros
- fix numerous places where code assumed that
nsXPConnect::GetXPConnect() does not add a new ref on the
xpconnect singleton object (the behavior changed some time back
but not all the uses did - brainfade!).
- fix nsXPCException::NewException to automatically trim
'dataless' native stackframes off of the front of a stack trace.
The old system of manually telling it how many frames to trim was
not working well. We really want the first frame showing to be an
'interesting' frame so that callers who get exceptions thrown at
them will see some useful information rather than an empty native
frame that represents (but says nothing about) some native frame
in the xpconnect runtime.
- remove an extra addref from the trimming loop in
nsXPCException::NewException.
- Stop building XPCJSStack objects. XPConnect stacks are singly
linked lists of XPCJSStackFrame objects with refcounted links. I
had this stupid idea that each object would have a refcounted
link to a XPCJSStack object that would tie together the lifetimes
of all objects in the chain. This was overcomplex and
unnecessary. The linked list was enough. Any frame without a
refcount deserved to be deleted because it is simply unreachable.
There was no reason to tie together all the lifetimes of each
object in the chain. So this has been simplified in a big way.
- fixed place in xpcthrower.cpp where we were leaking a refcount
on the xpconnect singleton each time an xpcexception was thrown.
- do cleanup and gc() at the end of xpctest_echo.js to use for
leak testing - all wrappers should go away.
Re: NPL vs. MPL
Date:
Wed, 06 Oct 1999 18:30:34 -0400
From:
"Ian D. Stewart" <idstewart@softhome.net>
To:
Norris Boyd <norris@netscape.com>
References:
1 , 2 , 3
Norris Boyd wrote:
Great. So I'd like to change this copyright text
/* -*- Mode: java; tab-width: 8; indent-tabs-mode: nil; c-basic-offset:
4 -*-
*
* The contents of this file are subject to the Mozilla Public License
* Version 1.0 (the "MozPL"); you may not use this file except in
* compliance with the MozPL. You may obtain a copy of the MozPL at
* http://www.mozilla.org/NPL/
*
* Software distributed under the MozPL is distributed on an "AS IS"
basis,
* WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
MozPL
* for the specific language governing rights and limitations under the
* MozPL.
*
* The Initial Developer of this code under the MozPL is Ian D. Stewart.
* Portions created by Ian D. Stewart are Copyright (C) 1998, 1999
* Ian D. Stewart.
* All Rights Reserved.
*/
to this:
/* -*- Mode: java; tab-width: 8; indent-tabs-mode: nil; c-basic-offset:
4 -*-
*
* The contents of this file are subject to the Netscape Public
* License Version 1.1 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.mozilla.org/NPL/
*
* Software distributed under the License is distributed on an "AS
* IS" basis, WITHOUT WARRANTY OF ANY KIND, either express oqr
* implied. See the License for the specific language governing
* rights and limitations under the License.
*
* The Original Code is ListenerCollection, released
* May 15, 1998.
*
* The Initial Developer of the Original Code is Ian D. Stewart.
* Portions created by Ian D. Stewart are Copyright (C) 1998, 1999
* Ian D. Stewart.
* Rights Reserved.
*
* Contributor(s):
* Ian D. Stewart
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU Public License (the "GPL"), in which case the
* provisions of the GPL are applicable instead of those above.
* If you wish to allow use of your version of this file only
* under the terms of the GPL and not to allow others to use your
* version of this file under the NPL, indicate your decision by
* deleting the provisions above and replace them with the notice
* and other provisions required by the GPL. If you do not delete
* the provisions above, a recipient may use your version of this
* file under either the NPL or the GPL.
*/
Can you give me your approval for this change?
Make it so.
Ian
JSErrorReports when thrown as exceptions. Extract JSErrorReport
and convert to an xpcexception. This restores functionality that
was whacked when JS errors-as-exceptions was enabled in the JS
engine.
- add conversion support for string-with-length as part of array
support mentioned in bug 13420. All the array stuff is basically
in with minimal testcases. More comprehensive tests need to be
written to verify and tune the code.
- fix a broken #undef
- switch to using PR_Alloc/PR_Free internally in nsjsid where we
were using new/delete before. This is prompted by warren's change
to nsID::ToString that uses PR_Alloc were before it used new.
This fixes an alloc/delete mismatch detected by Purify.
r=mccabe
