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.
