Decoder not properly initialized on Windows

Volker Simonis volker.simonis at gmail.com
Fri Jul 15 02:22:28 PDT 2011


Thank you!

I'll file a webrev later today.

Just out of personal interest: can you explain to me what the numbers
(in this case '4/4') in front of the bug description mean. I see them
from time to time but couldn't figure out there meaning.

Regards,
Volker

On Thu, Jul 14, 2011 at 7:59 PM, Daniel D. Daugherty
<daniel.daugherty at oracle.com> wrote:
> New bug filed for you:
>
> 7067266 4/4 Decoder class not properly initialized on Windows
>
> Dan
>
>
>
>
> On 7/14/11 8:33 AM, Volker Simonis wrote:
>
> 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));
>


More information about the hotspot-runtime-dev mailing list