Context.reportRuntimeError() in compiled mode
Thomas Hentschel
within a LiveConnect call.
Reporting of source name and line number works as it should when in
interpreted mode [Context.setOptimizationLevel( -1 ) ].
This doesn't work when in compiled mode [ I'm compiling a script and
execute it later via exec() ]. Context.setGeneratingDebug() and
Context.setGeneratingSource() is both set to true.
Is this supposed to work ?
Moreso, when switching from interpreted mode to compiled mode, the source
file / line number values from the last failed invocation are kept,
even though execution fails somewhere else. [ adding mightily
to my confusion ]
-Th
Norris Boyd
>I'm trying to use "Context.reportRuntimeError( msg )" from
>within a LiveConnect call.
>
>Reporting of source name and line number works as it should when in
>interpreted mode [Context.setOptimizationLevel( -1 ) ].
>
>This doesn't work when in compiled mode [ I'm compiling a script and
>execute it later via exec() ]. Context.setGeneratingDebug() and
>Context.setGeneratingSource() is both set to true.
>
>Is this supposed to work ?
>
This is all implemented in Context.getSourcePositionFromStack. It's a
bit of a hack, but I don't know of any other way to get source line
information from executing code. I would expect it to work--it uses
Exception.printStackTrace and then munges the output to find non-java
source files. You can debug this by looking at the result of
writer.toString() and seeing the stack trace there. Either the
information isn't making it into the stack trace or there's some bug in
the code that searches through it looking for the line number.
>
>
>Moreso, when switching from interpreted mode to compiled mode, the source
>file / line number values from the last failed invocation are kept,
>even though execution fails somewhere else. [ adding mightily
>to my confusion ]
>
When writing Context.getSourcePositionFromStack I didn't plan on people
mixing compiled and interpreted scripts. Basically, you might need to
insert code to clean up the interpretedLine variable in Context. Here's
one place: upon return from an interpreted function. If this works for
you let me know and I'll commit the change.
Index: InterpretedFunction.java
===================================================================
RCS file:
/cvsroot/mozilla/js/rhino/src/org/mozilla/javascript/InterpretedFunction.java,v
retrieving revision 1.21
diff -u -r1.21 InterpretedFunction.java
--- InterpretedFunction.java 27 Sep 2001 02:33:48 -0000 1.21
+++ InterpretedFunction.java 13 Dec 2001 15:29:16 -0000
@@ -93,6 +93,7 @@
itsData);
}
finally {
+ cx.interpreterLine = 0;
if (itsData.itsNeedsActivation) {
ScriptRuntime.popActivation(cx);
}
>
>
>-Th
>
>
Thomas Hentschel
wrote:
> Thomas Hentschel wrote:
>
>>I'm trying to use "Context.reportRuntimeError( msg )" from within a
>>LiveConnect call.
>>
>>Reporting of source name and line number works as it should when in
>>interpreted mode [Context.setOptimizationLevel( -1 ) ].
>>
>>This doesn't work when in compiled mode [ I'm compiling a script and
>>execute it later via exec() ]. Context.setGeneratingDebug() and
>>Context.setGeneratingSource() is both set to true.
>>
>>Is this supposed to work ?
>>
> This is all implemented in Context.getSourcePositionFromStack. It's a
> bit of a hack, but I don't know of any other way to get source line
> information from executing code. I would expect it to work--it uses
> Exception.printStackTrace and then munges the output to find non-java
> source files. You can debug this by looking at the result of
> writer.toString() and seeing the stack trace there. Either the
> information isn't making it into the stack trace or there's some bug in
> the code that searches through it looking for the line number.
>
Here is the stack trace as seen from within
Context.getSourcePositionFromStack() :
"java.lang.RuntimeException
Stack trace:
java/lang/Throwable.<init>()V
org/mozilla/javascript/Context.getSourcePositionFromStack([I)Ljava/lang/String;
org/mozilla/javascript/Context.reportRuntimeError(Ljava/lang/String;)Lorg/mozilla/javascript/EvaluatorException;
test/TestTimer.check()Z
java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
org/mozilla/javascript/NativeJavaMethod.call(Lorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;Lorg/mozilla/javascript/Scriptable;[Ljava/lang/Object;)Ljava/lang/Object;
org/mozilla/javascript/ScriptRuntime.call(Lorg/mozilla/javascript/Context;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Object;Lorg/mozilla/javascript/Scriptable;)Ljava/lang/Object;
org/mozilla/javascript/gen/c3.call(Lorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;Lorg/mozilla/javascript/Scriptable;[Ljava/lang/Object;)Ljava/lang/Object;
test/TestThread.doRun()V
test/TestThread.run()V
java/lang/Thread.run()V
"
TestTimer.check() is the call having the exception, but a ".js" or a colon
is nowhere to be seen in this trace, so I guess the needed info is not
making it into the trace.
Is that something VM specific how a trace is formatted ?
Also, it looks like "sourceName" from the call to "compile*()" is
getting saved as a property in the function/script objects,
couldn't that be used for the source name ?
As for the line number, not sure how that could be done,
(dreaming>
but if it were to function, it would be nice to have it match the
"decompile*()" output :)
</dreaming>
>
>>
>>Moreso, when switching from interpreted mode to compiled mode, the
>>source file / line number values from the last failed invocation are
>>kept, even though execution fails somewhere else. [ adding mightily to
>>my confusion ]
>>
> When writing Context.getSourcePositionFromStack I didn't plan on people
> mixing compiled and interpreted scripts. Basically, you might need to
> insert code to clean up the interpretedLine variable in Context. Here's
> one place: upon return from an interpreted function. If this works for
> you let me know and I'll commit the change.
>
> Index: InterpretedFunction.java
> =================================================================== RCS
> file:
> /cvsroot/mozilla/js/rhino/src/org/mozilla/javascript/InterpretedFunction.java,v
> retrieving revision 1.21
> diff -u -r1.21 InterpretedFunction.java --- InterpretedFunction.java
> 27 Sep 2001 02:33:48 -0000 1.21 +++ InterpretedFunction.java 13
> Dec 2001 15:29:16 -0000 @@ -93,6 +93,7 @@
> itsData);
> }
> finally {
> + cx.interpreterLine = 0;
> if (itsData.itsNeedsActivation) {
> ScriptRuntime.popActivation(cx);
> }
>
>
Well, this would be needed in InterpretedScript as well. Since both
(InterpretedScript and InterpretedFunction) use Interpreter.interpret(),
wouldn't this be better done at the end of interpret() ?
If the exception is thrown while within the
interpret() method, the source/line info would be there, but once
the interpreter is exited, I think it should loose all knowledge as
to where the last runTimeError was reported.
Just my $.02
-Th
Norris Boyd
Yes. This is non-standard. What VM are you using?
>
>
>
>Also, it looks like "sourceName" from the call to "compile*()" is
>getting saved as a property in the function/script objects,
>couldn't that be used for the source name ?
>
Yes, it should be. For classes compiled to java bytecode, we put the
source name and line number in the generated class file the same way a
Java compiler does.
>
>
>As for the line number, not sure how that could be done,
>(dreaming>
>but if it were to function, it would be nice to have it match the
>"decompile*()" output :)
></dreaming>
>
All the decompile output is canonicalized. We didn't make any attempt to
match up line numbers. For debugging, I expected people to refer to the
original file (or web page or whatever).
>
>
>If the exception is thrown while within the
>interpret() method, the source/line info would be there, but once
>the interpreter is exited, I think it should loose all knowledge as
>to where the last runTimeError was reported.
>
Might be useful to maintain after an error, but I guess in that case the
information would already be put into the thrown exception. So yes,
perhaps it should be cleaned up on exit from interpret().
>
>
>Just my $.02
>
>-Th
>
>