Decoder not properly initialized on Windows

[Volker Simonis]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decoder.patch
Type: text/x-patch
Size: 1142 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110714/89266cbf/attachment.bin