Via e-mail from Volker:
Hi,
it seems that after "7003748: Decode C stack frames when symbols are
presented (PhoneHome project)"
(http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2d4762ec74af)
it can happen that the Decoder class is not properly initialized on
Windows:
In frame.cpp in 'print_C_frame()' there's the following code:
676 if (!in_vm || Decoder::can_decode_C_frame_in_vm()) {
677 found = os::dll_address_to_function_name(pc, buf, buflen, &offset);
678
679 if (found) {
680 st->print(" %s+0x%x", buf, offset);
681 }
682 }
If 'in_vm' is false, 'Decoder::can_decode_C_frame_in_vm()' won't be
called and the Decoder class will not be initialized.
'print_C_frame()' is only called from 'frame::print_on_error()' which
in turn is called directly in the steps 60 and 120 of
'VMError::report()' and indirectly through
'VMError::print_stack_trace()' in the steps 130 and 135 of
'VMError::report()'. But only the call from step 120 properly
initializes the Decoder class before calling 'frame::print_on_error()'
by construction a local Decoder object:
// initialize decoder to decode C frames
Decoder decoder;
The problem only manifests itself on Windows, because the Unix
implementations of the Decoder class don't require an initialization.
I would suggest the attached patch which moves the Decoder
initialization from 'VMError::report()' right into the
'print_C_frame()' method (which is the place where it is actually
required).
If somebody would be so kind to create a bug for this issue I can also
submit a formal webrev if required.
With best regards,
Volker
decoder.patch
diff -r b16582d6c7db src/share/vm/runtime/frame.cpp
--- a/src/share/vm/runtime/frame.cpp Thu Jul 07 10:51:07 2011 -0700
+++ b/src/share/vm/runtime/frame.cpp Thu Jul 14 16:30:26 2011 +0200
@@ -673,6 +673,7 @@
// names if pc is within jvm.dll or libjvm.so, because JVM only has
// JVM_xxxx and a few other symbols in the dynamic symbol table. Do this
// only for native libraries.
+ Decoder decoder; // initialize decoder to decode C frames
if (!in_vm || Decoder::can_decode_C_frame_in_vm()) {
found = os::dll_address_to_function_name(pc, buf, buflen, &offset);
diff -r b16582d6c7db src/share/vm/utilities/vmError.cpp
--- a/src/share/vm/utilities/vmError.cpp Thu Jul 07 10:51:07 2011 -0700
+++ b/src/share/vm/utilities/vmError.cpp Thu Jul 14 16:30:26 2011 +0200
@@ -566,9 +566,6 @@
if (fr.pc()) {
st->print_cr("Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)");
- // initialize decoder to decode C frames
- Decoder decoder;
-
int count = 0;
while (count++ < StackPrintLimit) {
fr.print_on_error(st, buf, sizeof(buf));
Hi,
it seems that after "7003748: Decode C stack frames when symbols are
presented (PhoneHome project)"
(http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2d4762ec74af)
it can happen that the Decoder class is not properly initialized on
Windows:
In frame.cpp in 'print_C_frame()' there's the following code:
676 if (!in_vm || Decoder::can_decode_C_frame_in_vm()) {
677 found = os::dll_address_to_function_name(pc, buf, buflen, &offset);
678
679 if (found) {
680 st->print(" %s+0x%x", buf, offset);
681 }
682 }
If 'in_vm' is false, 'Decoder::can_decode_C_frame_in_vm()' won't be
called and the Decoder class will not be initialized.
'print_C_frame()' is only called from 'frame::print_on_error()' which
in turn is called directly in the steps 60 and 120 of
'VMError::report()' and indirectly through
'VMError::print_stack_trace()' in the steps 130 and 135 of
'VMError::report()'. But only the call from step 120 properly
initializes the Decoder class before calling 'frame::print_on_error()'
by construction a local Decoder object:
// initialize decoder to decode C frames
Decoder decoder;
The problem only manifests itself on Windows, because the Unix
implementations of the Decoder class don't require an initialization.
I would suggest the attached patch which moves the Decoder
initialization from 'VMError::report()' right into the
'print_C_frame()' method (which is the place where it is actually
required).
If somebody would be so kind to create a bug for this issue I can also
submit a formal webrev if required.
With best regards,
Volker
decoder.patch
diff -r b16582d6c7db src/share/vm/runtime/frame.cpp
--- a/src/share/vm/runtime/frame.cpp Thu Jul 07 10:51:07 2011 -0700
+++ b/src/share/vm/runtime/frame.cpp Thu Jul 14 16:30:26 2011 +0200
@@ -673,6 +673,7 @@
// names if pc is within jvm.dll or libjvm.so, because JVM only has
// JVM_xxxx and a few other symbols in the dynamic symbol table. Do this
// only for native libraries.
+ Decoder decoder; // initialize decoder to decode C frames
if (!in_vm || Decoder::can_decode_C_frame_in_vm()) {
found = os::dll_address_to_function_name(pc, buf, buflen, &offset);
diff -r b16582d6c7db src/share/vm/utilities/vmError.cpp
--- a/src/share/vm/utilities/vmError.cpp Thu Jul 07 10:51:07 2011 -0700
+++ b/src/share/vm/utilities/vmError.cpp Thu Jul 14 16:30:26 2011 +0200
@@ -566,9 +566,6 @@
if (fr.pc()) {
st->print_cr("Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)");
- // initialize decoder to decode C frames
- Decoder decoder;
-
int count = 0;
while (count++ < StackPrintLimit) {
fr.print_on_error(st, buf, sizeof(buf));
- relates to
-
JDK-7071311 Decoder enhancement
-
- Closed
-