clear exception state before and after calling out via xpconnect.
remove redundant exception clear from CallQueryInterfaceOnJSObject.
git-svn-id: svn://10.0.0.236/trunk@102170 18797224-902f-48f8-a5cc-f745e15eee43
- The most significant fix, to keep JSStackFrame.spbase, the operand stack base pointer for an active frame, null except when there is an operand stack allocated and in use by js_Interpret. Previously, spbase would point after args and local vars (if any), then advance upon allocation of the (possibly discontiguous) operand stack space. This made for a fatal ambiguity: js_AllocStack, called by XPConnect, could not tell when there was allocated operand stack space above the frame's sp, which needs to be set to a known (JSVAL_VOID) state for exact GC to work. Now, the GC doesn't have to mark any operand stack space for a frame whose spbase is null, and js_AllocStack doesn't need to void any unused space for such a frame.
- Fixes to reload the JSRuntime's callHook or executeHook after calling or executing, in case the debugger removes the hook. In which case, it must clean up any dynamic memory held by hookData, but in any event, in which case the engine must not call the post-call or post-execute hook.
- While debugging with rginda, I was horrified to see his trivial testcase function, expressed as a lambda, fail to be invoked using the "inline_call" machinery in js_Interpret (which avoids js_Interpret recursion through js_Invoke for most JS functions). The problem was a test of fun->flags == 0 conditioning the /* inline_call: */ code. Since that test was written, at least one JSFUN_* flag (JSFUN_LAMBDA, used only for pretty-printing or accurate decompilation) has been added. But all along, that test was an over-optimization (testing against 0 without &'ing certain flags), making for an accident waiting to happen -- which did happen. The relevant flags are JSFUN_HEAVYWEIGHT (set by the compiler when a function calls eval, uses with, or otherwise needs an activation object for its scope; if lightweight, the compiler can see the function's scope and eliminate it via specialized bytecodes) and JSFUN_BOUND_METHOD (for Java method calls, where |this| binds statically to the instance, not dynamically to the calling expression reference's base object, as in JS).
git-svn-id: svn://10.0.0.236/trunk@102100 18797224-902f-48f8-a5cc-f745e15eee43
spruce up some comments
added, then comented out, jsdIDebuggerService::filterGlobalObject
git-svn-id: svn://10.0.0.236/trunk@101914 18797224-902f-48f8-a5cc-f745e15eee43
don't allow gc's during script hooks if CAUTIOUS_SCRIPTHOOK is defined (which it is, by default.) Should help with stability until we can fix the real problems.
Use JSVAL_ macros instead of JSD_* calls in jsdValue::GetJSType method, avoiding two c++ frames per call.
git-svn-id: svn://10.0.0.236/trunk@101912 18797224-902f-48f8-a5cc-f745e15eee43
fixed up access paths: get rid of :::dist:client[_debug]
r=jfrancis
sr=sfraser
a=asa on behalf of drivers
git-svn-id: svn://10.0.0.236/trunk@101856 18797224-902f-48f8-a5cc-f745e15eee43
Also, fixes for :
#91343, (non-latin1 fails for [\S])
#78156, (Unicode line terminator matching)
#87231, (/(A)?(A.*)/ didn't reset paren state for empty first match)
git-svn-id: svn://10.0.0.236/trunk@101837 18797224-902f-48f8-a5cc-f745e15eee43
improvements:
Subject:
Rhino: Problem in NativeJavaMethod
Date:
Tue, 14 Aug 2001 10:23:35 +0200
From:
felix.meschberger@day.com
To:
Norris Boyd <nboyd@atg.com>
Hi Norris,
While working with wrapped Java classes we discovered a problem in
NativeJavaMethod : If the public method to be called is part of a
non-public class, the Sun Java VM throws an IllegalAccessException. This
bug in the Sun VM has been reported as Bug 4071593 to Sun, but has not been
resolved since....
I implemented a circumvention, for which I provide you the patch. I quickly
tested it, and it seems to work.
Regards
Felix
And here's the patch :
diff -w -r1.19 NativeJavaMethod.java
227a228,234
> /**
> * Due to a bug in Suns VM, public methods in private
> * classes are not accessible by default (Sun Bug #4071593).
> * We have to explicitly set the method accessible beforehand
> */
> meth.setAccessible(true);
>
-----------------------------------------------------------------
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying to
this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble-free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:felix.meschberger@day.com
http://www.day.com
Felix Meschberger
Development
Day Interactive AG
Steinenberg 21-23
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
git-svn-id: svn://10.0.0.236/trunk@101768 18797224-902f-48f8-a5cc-f745e15eee43
Rhino: Problem in NativeJavaMethod
Date:
Tue, 14 Aug 2001 10:23:35 +0200
From:
felix.meschberger@day.com
To:
Norris Boyd <nboyd@atg.com>
Hi Norris,
While working with wrapped Java classes we discovered a problem in
NativeJavaMethod : If the public method to be called is part of a
non-public class, the Sun Java VM throws an IllegalAccessException. This
bug in the Sun VM has been reported as Bug 4071593 to Sun, but has not been
resolved since....
I implemented a circumvention, for which I provide you the patch. I quickly
tested it, and it seems to work.
Regards
Felix
git-svn-id: svn://10.0.0.236/trunk@101312 18797224-902f-48f8-a5cc-f745e15eee43
