This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Patch: FYI: PR libgcj/28352 - interpreter stacktrace
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: Java Patches <java-patches at gcc dot gnu dot org>
- Date: Wed, 12 Jul 2006 09:55:40 -0400
- Subject: Patch: FYI: PR libgcj/28352 - interpreter stacktrace
This patch fixes one of the problems with stack traces for interpreted
frames described in PR libgcj/28352. Since the interpreter advances the
PC before executing an instruction, we were actually looking up the line
number for the PC following the one which generated the exception. This
bug didn't seem to occur often for "gcj -C" bytecode, but it happens
often with ecj-produced bytecode, since ecj records a new line number
for the "return" instruction in a method.
I'm checking this in to trunk.
Bryce
2006-07-12 Bryce McKinlay <mckinlay@redhat.com>
PR libgcj/28352
* stacktrace.cc (getLineNumberForFrame): Roll back PC by 1 when
looking up line number for interpreted frame.
Index: stacktrace.cc
===================================================================
--- stacktrace.cc (revision 115369)
+++ stacktrace.cc (working copy)
@@ -182,7 +182,9 @@
_Jv_InterpClass *interp_class =
(_Jv_InterpClass *) interp_meth->defining_class->aux_info;
*sourceFileName = interp_class->source_file_name;
- *lineNum = interp_meth->get_source_line(frame->interp.pc);
+ // The interpreter advances the PC before executing an instruction,
+ // so roll-back 1 byte to ensure the line number is accurate.
+ *lineNum = interp_meth->get_source_line(frame->interp.pc - 1);
return;
}
#endif