Decoder not properly initialized on Windows

[Daniel D. Daugherty]

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));
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110714/913853e6/attachment.html