JDK-7067266 : Decoder class not properly initialized on Windows
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs22
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: windows
  • CPU: generic
  • Submitted: 2011-07-14
  • Updated: 2013-03-27
  • Resolved: 2013-03-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
hs24Resolved
Related Reports
Relates :  
Description
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));

Comments
JDK-7071311 changed the way how decoder is initialized, this issue no longer exists.
27-03-2013