Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7067266

Decoder class not properly initialized on Windows

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P3 P3
    • hs24
    • hs22
    • hotspot
    • None
    • generic
    • windows

      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));

            zgu Zhengyu Gu
            dcubed Daniel Daugherty
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: